From nobody Mon Dec 2 20:43:50 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Y2G3S2GRYz5gPnc for ; Mon, 02 Dec 2024 20:44:04 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx-01.divo.sbone.de (mx-01.divo.sbone.de [IPv6:2003:a:140a:2200:6:594:fffe: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 ECDSA (P-256) client-digest SHA256) (Client CN "mx-01.divo.sbone.de", Issuer "E6" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Y2G3P4Tw8z3xvt for ; Mon, 2 Dec 2024 20:44:01 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zabbadoz.net header.s=20240622 header.b=ma3jOsJ9; spf=pass (mx1.freebsd.org: domain of bzeeb-lists@lists.zabbadoz.net designates 2003:a:140a:2200:6:594:fffe:19 as permitted sender) smtp.mailfrom=bzeeb-lists@lists.zabbadoz.net; dmarc=pass (policy=none) header.from=zabbadoz.net Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by mx-01.divo.sbone.de (Postfix) with ESMTPS id DF4EDA64806; Mon, 02 Dec 2024 20:43:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=zabbadoz.net; s=20240622; t=1733172225; bh=seNPUpuxyPFdUgBx8gbMf74SYI3HutMB3JIG+bE5N3M=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=ma3jOsJ9z9Zebw426MJKs4JNRliZHpzW9YpC6XJfenmJOalC+NXj/17zNYL1XglzW 5JYb3YGgu356hVQFl8v0vk15m8FxHt1hgNdKU9/jSqAF3FocGBaOVMGfdM2ZGZJ4No BP0hcOqiuxJJwrL1whlgFHymribW9zwGx7f9zQqngLEiMI/pJPDKOkHBWiE4WC5/yz 1W10o3lPKpj3IHhrYY6crPn2teqkMCypt+Sz9QJvGVO5HDULY6Q+hEbeSSu0dvzx7I jutmEcGZXWZBrPrBij88EiXcPokBho3rpHzeHe3/HhY9o0nEfXy5jOpVUSrPwBIEz0 409/h8vQEsxjCgO5p9xlXbal3vI0MdHOeMySC9belAXgTEtrWwI9jCZeudkEXBzvCH lUQDs4/5OKQJAenEe2ZmeaZGFR7jyR5Owc6cp8hTtObDyD7Q2qu39XqbHKta1ZR0Ps kojXAPc47DdZ3BQ6XdfZdJgIrFGLuTqziG5OuJxKbV8Fn+0bg1tnVtQKrgmG0oWnaX x5EADPYIyDKdm/zC1kLCpAoS9Am9edtoc5ufLebVqn17sUoDm/2MddPFhvynpvxIgs GbsDvjidszllEoOg9iEPXsjf3UV53whSbZRpWocIDnLKbtcFjAd+Fc3ZlRNmm2QIpa s9tQnrMd7YCu0je8k9cdfNRM= 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 EEA4B2D029DC; Mon, 2 Dec 2024 20:43:51 +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 ulxS95lutobp; Mon, 2 Dec 2024 20:43:50 +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 61D482D029D8; Mon, 2 Dec 2024 20:43:50 +0000 (UTC) Date: Mon, 2 Dec 2024 20:43:50 +0000 (UTC) From: "Bjoern A. Zeeb" To: Mark Millard cc: freebsd-arm@freebsd.org Subject: Re: Raspbery Pi support (release notes/wiki page) update? In-Reply-To: Message-ID: <7sp0np90-0rnn-n327-qps0-358493p411rs@yvfgf.mnoonqbm.arg> References: <668r286o-584q-616o-5nq3-0233r3259qsr@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: text/plain; charset=US-ASCII; format=flowed X-Spamd-Result: default: False [-2.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.97)[-0.974]; DMARC_POLICY_ALLOW(-0.50)[zabbadoz.net,none]; R_DKIM_ALLOW(-0.20)[zabbadoz.net:s=20240622]; R_SPF_ALLOW(-0.20)[+ip6:2003:a:140a:2200:6:594:fffe:19]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; MISSING_XM_UA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:3320, ipnet:2003::/19, country:DE]; FREEMAIL_TO(0.00)[yahoo.com]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[zabbadoz.net:+] X-Rspamd-Queue-Id: 4Y2G3P4Tw8z3xvt X-Spamd-Bar: -- On Wed, 27 Nov 2024, Mark Millard wrote: I assume that all also means there's no way on FreeBSD to update the eeprom contents on the RPi4/5[1] (contents replaced the bootcode.bin on older PIs.) /bz [1] https://github.com/raspberrypi/rpi-eeprom/tree/master/ -- Bjoern A. Zeeb r15:7 From nobody Mon Dec 2 21:43:34 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Y2HNS6dP0z5gV71 for ; Mon, 02 Dec 2024 21:43:52 +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 4Y2HNS2GHHz4610 for ; Mon, 2 Dec 2024 21:43:52 +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=1733175830; bh=6LDl7W4+vwoT24ng9/tJUpj+kYAbOCBcR9YN9i/vig8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=isBfOhqb4zFrU/Inu7EQj/7JTld3suPKrTWhL0rupK5ovfsalxUOQxH7CIgF+duNjySeVU2mVLPZgTIWf5i7GAR1nhdohIx0NXgG62GVdmEpyCLrlYCexKBipkCy6CBHnYeTICrEreGZX87wxta7G31Yaa7EArXr/dD4xRPHQ/LV+I7N5ZfqN4GbyhirLzRnxirhcMEvUkTaqfvUKFExq/vblPGQ5oJ2XCXBXnpgMEXgUooAFB1TeLG260//lu+0uYhpXerZGigkefmBGo8ueqm2ZOdwS6UCiriKuzER2D8C5guC/dNTmBLlySdHovH3G/cgFgYgNSZsMJWGAY+T+Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1733175830; bh=q9o/ma6r/VcrjqAtTgc0uVwDm8ZVeQMtiR7ioEDeZCo=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=N59CjsgEAZVKadtmfXTjzDs6yrXjpEO1ilSZafs96Lycp1Ohg0rLma0Rf38ftDBC+RSvXvkKiEkTB3yiqTjMFvK9yVfsEatKRf2uVsmho2i0lfxkQ55k+sQ4yqSsbKhrdppYvsf1eywpLTdTMKJJoQfmWtGLPDwimR+/GTRZvkrc8H08jjQdyuv2ZbyAfPwuMPN95Qw0UF8ckm1Ei4HIrEFu5syjQ1S7azQvZWjGOICbVSgSpRfGpi63Sl4OPX/ki5TiDzt2rZJlWLuh+hbgiqX6aP9gP+r5mtt1ODv2Q/ZQgFfInfDvguj22ItBc05Ozs756Wx4Vl+sXhCBA4P/Og== X-YMail-OSG: tqO2uIQVM1kgOX9nAwmUbslFaYviQknZAQ0WtuxTo3rDZVvZhKQ1HzaWQUXM5Iz jvCN9Xlmd9vHYt5iff3fKNz8nlBRYXLaajvV9JI7QKl2R241Gylz8C5JmqulcxbnXj.VCFJKfUqT E4jdA_ILEp7wfj65kAGZMQ1pNXUCqvhnRlkVvMnhpA2qwgUDi2.FCaGzpVOAdnzdCdT9Ue7nvd_E ZH.YCDCWiDBPWZuSUBPkx58Zepyyrwk0UXAT6p1cl7thfWB1piiCSpYovMKIjH1.STRm44monEB0 .VDAkle8zFheeJuclcQQX5XVHhXXC5iXZlCgsVswBm5TxR45OCZ6OO_j3C69LKjyZyCG0J9ob_zI dBKAD2by7kUMx7_lZXfaXwBc79P042YbgpQu7GTUvDi1anAZwB9pFTfSSC1EvI5sp37W.m6jsafQ vCWWkkLe8yXXwSi..9nLQn8UxOm8welalObqzZFonCpaJa.BwSphVwl9WcnXQ5DnR1obXI64p6SO hZ4d9WMQgOu87NQWWM6DYtroff9Yugng_rk16WCvs475RC4j_a1gFSCicJWqqJjbsRhgW9G.BQmY ncium3AoQ7Q.SKG0QtlCdawjXoL5OKFAZKRyFBuI1lkO6d.9VbiVvraOLHgJ48TfW2H707LLvcKo _ykkT4g48Zh_Nw9Uheq5EhkGhVOahd2EhN332AqBxPR.u_HRE6MJhW7dUfqjfQ08K9PKqDPYC.Ll _rpaTeOEZiqhNHVhSYf2Jw5IT6GUqLevN.mYDVUJyp5powvQNCJwzfnQlZLpNm.TLtNDYkDXVEtK ep0cygjDHOyMja0DIYavYh6fFLFoQazaMCIPaC5uhn9datl1hlAA9hj7v2qmssT4ZoxoiTid5zXc c3ggsbzq_pB.VLwmy9Pim4vze7pwfqLjoLE70CViDILyrMvF3ayrfvslPfxbItQX4i1FLJAB62yN eQTn2Rxk7Xwg4NWKerN5jvg4fsmiz2bhrI..6N15ywWCtNgBQttlqYvFXT8jxsYfz_C0iUaqZVR4 BpKMSXYm6L_i.4PBbXAgktmvjdNYC7qguDonoHSy11KNNls6FgimsAvbsT2UtkKNDCxz.FMN8laq VH2QSmx8.9QV5uNFKKCBn0CGq8pQ3xMinmnc_XUpqfU_0CBiGjdz.Ndcmuu5xzbLAzA4xa0AcCNV Y.r5QWf42LamLgqDTNxRweqva4F9JTa6ND9sapOix41NhzQBQgydfjvukRNKEXUgECiUKV9QIHTK yfhqC8EAD9Eyurn1CBvgkVDURlXJkDgzBrDExFVhZbi1SO2DvUjejuTHUIgDdOecSDrRnKm6rz0Y WScnF9mjFC1JqwEpHwx3x_GA.scea7blWBNsUyNibmVhWOx4VZ620mc2c6nTJIOzII1qP6aFtitc dSwShL05BUJ5UYTo1rJiGViBTa.j.Ncvnj1a4Lk9CO4QMb1yIOg5P1kzpk1A7rDZkC2X7UvNdkJU rl267XE6rcbZyTZiriMwBzmJaRXNqgwYhqdlFtkTzx829NkOyYF1a_cB7nUSW0Yv8IA8B0mheWCZ ohhIRqPQ7rYcf4wZ8ZrkthlBbAahzcwmYgax14ZTvIEFcc17a07KgDwUSrNsxZD6nyDXy9ZKTzUH KcwYUAlCGwF0FrFlbGvI.IOezIigifXn40ZGY1FMDyhsat9s.9vlGnj3CJN.kodRFvYc7MmESJlI NvHGwiWtqaSVC7AeF1e01TnX9MMPnfKddnu_8o9SodrFMsXNvYC5xZeqTEqtEgWoC3Wl9uga4h0h qgsT1g12K2oFPr6.ZyP49YFJof3it.C9g9BiozXi_bvekB5d.wp_uO.Nw6Hve22.VEMWwo5T6uYd wnTutmpypdH6Z0vuqbD3g8UgdMGTVMk1dpcImtOB3xxSiLH9it_5AndInDM2ebrOJOlAXh9.PUTL xV3499VUwg2AN4rwE..wiM5nU6wBtcXpUD6TL9oUIrdUvKFuvnWEsOZuHhJZ2AVof4T7S2kDXGH6 luGK.8UXqKzIm5HKYl_fwma9u7UeVOHc1xUaMVeE55qXZ0xJ7gpIBstKaeOuEfgE68hrMNqYhDAp Z9TEvn_RvLkRg1zOzlw4BUszKdcCSqwKc48Rq5qXalJBVo46N3OcH56whtxh2dsbc42aG45fkIJd obGTwRXQwxO4RPodKf7MHGQ.qD8ZrWBdrGaiG62N9TnZow1ixb4B90UkxPxr2t3cP5Xooh7vcXtG JYkbaWKDJahhYVq4B9y7Qvx33JmqG5Fwcy2mbTQUNv5NOsjnFNLfjlx8olgDyOlnlPfWAZxKpVIs L2S0_Dc8S X-Sonic-MF: X-Sonic-ID: f8c30fbd-a555-457a-afc8-4adfd2f4182f Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Mon, 2 Dec 2024 21:43:50 +0000 Received: by hermes--production-gq1-5dd4b47f46-9j75b (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID cbc17f5fcae43d2aa538320538d6bceb; Mon, 02 Dec 2024 21:43: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 \(3776.700.51.11.1\)) Subject: Re: Raspbery Pi support (release notes/wiki page) update? From: Mark Millard In-Reply-To: <7sp0np90-0rnn-n327-qps0-358493p411rs@yvfgf.mnoonqbm.arg> Date: Mon, 2 Dec 2024 13:43:34 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <68B36F4A-76AD-4CEC-ACBA-3EEF6863BB04@yahoo.com> References: <668r286o-584q-616o-5nq3-0233r3259qsr@yvfgf.mnoonqbm.arg> <7sp0np90-0rnn-n327-qps0-358493p411rs@yvfgf.mnoonqbm.arg> To: "Bjoern A. Zeeb" X-Mailer: Apple Mail (2.3776.700.51.11.1) 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-Rspamd-Queue-Id: 4Y2HNS2GHHz4610 X-Spamd-Bar: ---- On Dec 2, 2024, at 12:43, Bjoern A. Zeeb = wrote: > On Wed, 27 Nov 2024, Mark Millard wrote: >=20 > I assume that all also means there's no way on FreeBSD to update the > eeprom contents on the RPi4/5[1] (contents replaced the bootcode.bin = on > older PIs.) I update the EEPROM's via booting a standard RaspiOS64 (my = abbreviation). That includes updating some defaults/definitions that can be stored in the EEPROM. (For example, I enable more debug output than is the default. That includes enabling BOOT_UART .) There are commands like: sudo -E rpi-eeprom-config --edit I'm not aware of FreeBSD having any such software, even via the ports tree. However, the description of the command is: QUOTE Editing the current bootloader configuration The following command loads the current bootloader configuration into a = text editor. When the editor is closed, rpi-eeprom-configapplies the = updated configuration to latest available bootloader release and uses = rpi-eeprom-update to schedule an update when the system is rebooted: END QUOTE In essence doing a (after the edit): sudo rpi-eeprom-update -a I do not have the references handy, but as I remember, this puts a file in the msdosfs that, if found at (re)boot, is automatically used to do the EEPROM update, well before U-boot is involved. So: putting a correctly formed file in the right place with the right name for a reboot to pick up is basic to the EEPROM update operation. The EEPROM contains the bootloader. The RPi5B has less that goes in the msdosfs (on the microsd card I use to boot the RPi5 via a separate USB3 drive): # find /RPi5-edk2/ -print /RPi5-edk2/ /RPi5-edk2/RPI_EFI.fd /RPi5-edk2/config.txt /RPi5-edk2/bcm2712-rpi-5-b.dtb Nothing analogous to start4*.elf or fixup4*.dat is involved. # more /RPi5-edk2/config.txt armstub=3DRPI_EFI.fd device_tree_address=3D0x1f0000 device_tree_end=3D0x210000 # Force 32 bpp framebuffer allocation. framebuffer_depth=3D32 # Disable compensation for displays with overscan. disable_overscan=3D1 # Force maximum USB power regardless of the power supply. usb_max_current_enable=3D1 # Force maximum CPU speed. force_turbo=3D1 # # Local additions: enable_uart=3D1 uart_2ndstage=3D1 dtdebug=3D1 disable_commandline_tags=3D1 # [pi5] over_voltage_delta=3D100000 arm_freq=3D2600 [all] > /bz >=20 >=20 > [1] https://github.com/raspberrypi/rpi-eeprom/tree/master/ Releases: https://github.com/raspberrypi/rpi-eeprom/releases Tagged: https://github.com/raspberrypi/rpi-eeprom/tags (More is tagged than is eventually declared to also be a release.) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Dec 3 07:38:23 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Y2XZp2wrnz5g0fX for ; Tue, 03 Dec 2024 07:38:42 +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 4Y2XZm5GNpz4Lnp for ; Tue, 3 Dec 2024 07:38:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=NU8uIr2g; 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=1733211518; bh=Xo8+DOHDSrz3a1aQZ171HlAju+6znOxPxYfNKu5j/54=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=NU8uIr2gGPUGDMOCr29qb/xDMPIKTx40vIYD5AzJ9lYaUJXmAwxcb0x9v6Zmd3nvfB4bm8A7Jx2eOW0eumRYdXZ5klUgVmK5iz9WW2LGR4mYbW3aS7IWv1MXbzwBqkraYS7njg/3KX233GxmrpFT8ddciFlfrQZp+UP58ZpWnvZwasnMhV1OLjtsU+n4jzMBscrJS/CdPpd3JaX6BRVB4EFjZXTr76PiI5/Xf+tnHQycbcfsIlYx47ZDtka7CfYHIG5+4inHXif7J7yBj2uBotftjlitMr0IC1GhPmI9TEL8UFM6kT1sd8d3HbNL1YGUVsm9IJdNh2QgFBTm41t54A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1733211518; bh=/3YIqsY0jG6VvYEhJVPHDZosj+UgSg/tT1jsmoNSk1q=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=G2TwK7l9YKnX8jqBUjGO2wX3nD5tVj8mtCOze7Esk6qsLKsLBeHCaJihTS9Xg0whcS4E/xuPKj6NF87eRO/0caMWUW5JcOjwDEEVBvZ2e8oPvjU9eDILdKlrR+T/pnOh3T2OkPnmYB9lS7ubXJEWpqnZU5o8HTdpO0woL3C6Vx2yP6YxNEZQDboA2SemTH0gGlzOkwzjbSpvRFp4UirG9YvvwoPLHZ/eW+B5cWiRMYvwNqbgxfEgE1o6xjR8ZGYNgwwiWkKPaDiFSENiDTgKicwfB2NYhxFtVUG8jMWyMV2ZlM1yUs3bbxyEmkVGqiNI8uL0q3oRwyuwCQiQtgE8aQ== X-YMail-OSG: CojYWFkVM1kb_otZDMI06zp6Ypbbj_MDnwuu73exu.V0uVbQ68_NQHK5I8Yz9Il 1Dq6vvCGaZBSVnONIQojcMvp5uUVPK2ygwKmhyM5WAv6K9q8gfRPb3OjZa3OFfKV3x_MA09iuelE ml8UpV_4F_YINT24kvVAL12YqnGycL_KObz.AHoEepFjLO7bdTpIxl8C5kVIIeXQW9W.QNeU7WML MzK24iN32Nj839sj3ppaS_XRUXAPUDqtWqZkM3kY_a3AUhchSHhVl2VoZR6eKSKQbRiui4g78H6l M7VDxBQArcAoZHIojF1GYpAlohIfeiaLTn6aCuvV93t8MezJ4P2.6y6XyLMrI8DhfmVH4CtDVn6q 4pZqWI0FKmDuED60ZVw.qDEoehx5qjODdg9d4Er2btpoQrz_PyLbtpQoY81JPZEFnV51yvlTbJ8g vqLP9q29fOZun31i.B9kszZodYIogj_68OBHzpHH4ClkoGMzqY4Lc5MwcAAkhoxm2wNlcpJrkf8K GJ6HDRleTiJtpA_WNhBqkMG_evTsxkf8dbUc1p7PEX54ph.y3ebkzIoY_mkg1eH3PigDhE8Vr7KY 8u5ftJL8neu.Mx3.tQHJtlSdd5mf0aQOa.1D375f9nJ1Q5w1pw_n1gTTo8vxM8KLvJIUfSvAwUXz ywFGU8HB8Bs0PAp2IRUlf1Jl6dkzOhIXngcxIipHBSQo3GblU.X3EWGIU2zILGd82ELcza.SdiOx uBv6jW3nC96QzdBd8Ii3nfUslXneYiNpfZV.mnRhslK1OX0wnKDVmFmoIOsU2tzjYtMxMrdWe8Fu rfF9aHDlO.lK0oSvV5A3dyliuFd54WIwAamTjlV8S0HfS7kV5hjfkVCNo5ZfQtyXfQLkDuB2jFe1 3uWw_OqH0ypK.La2_i99JamakZo.zBeydVE7tGfM8.UtEsRIVoujDLrun0197zwVbdUOQNoIQ.Cg J4v8yDuWJ5SZ522n7IBfdrLdPSxN9VTyMXCQCvzIod4uKEjTwcgVtctj0COUlJ2JyCnFd2lAZnpl mRfAt7e51zJu0NBeeduX4ULsy_.YOltBomm1oXHemE.31nRPNf95TrYI4frFZKDwwpq00QIB.4Ui sDOzsfsec579QTTCD_40Z67KYTWPJriy9FXC54goRzOyqBfdB_CGqDTdD2ys4otTIpNVrervH3.y K47i626qWbMSnd4NL.c3DZbSu9xO6ipkTMcISiryVywQPZN346.myKorehwSP_ZfS5RqrZb_Lq5A UstLkV3SgwG15ZwEj9Q4Q6jFm5fNkrUaZ8NpZ.GPuaGgK2kG2QKDfUI9skhcJK3XeRK2AMwwCOKN y7Xqr5mHxF6stqLV.jWL.ie6IfXupOx6gXLa2uWhyW_etdk69X7BmGnE0dv1hCG0XbuUCzrM1ggx Z0VUnsPbyjniqHVp0IqNVb_wuPYzwkCiMHu3ksmsjiN57I05SRzRseKsd_j9w0gLh2_flAHffJxA l.HNFPFdKmonWNQJVfHJ5_CMdcsehnKzd7EoXki6iEcqydGmMioDaX2T9p85luMGmAMIBMnv5nrW 7Qyt_hwc8udTfrwIkd6JOFYwU_M3tuO0OkpocjbLJDoMHk23zJR.cdU.XJzlxbisZVvjMAOOHluq Kgydk5RKsA6PUVP_jAkYhtkvcJZJyUJOEniPb6oqwSvGrSTVjxmyI_P_6dWF6ResS2Zc_jFyw_8u _ykNUvQGg6ihARXl_ni.Uh28m2thD20ISenhlePijTab9m.dqAeQ5oBCuoTP1fn.YyvAGd_NxUng OowpfrkAXugDvietOqfbXgUZlBzkeix0Uzim7ZIZ3JAu_.ZkecRVMlIpnXiFt8Lv1CrdGrF.61iE f9EdY57F4FRUKYrJYSBj1_R4ThlSAheDPkP42Cj0ExiMGJRLx1axnjSHcwyyAtihmKwEfLXlDke4 Fo.v5IRteRfjjZ6MECmwQD3b_8fcITvPsOdXQj6Y7Sub_KzX9OQwEx_7Q8y2Z4JLjWsP05cg7XJ0 DhD7NRlNY6ngO5Oso8fMSY.WDobO1c_KTHYloaEVaC31XvMPMjuZ9YAbxBIKsjj2z_e.3mzX8IB6 wh1hNr7ppqgZCCNiN3DObFn68zpKHEteoAIZz2fsQX400gZ.QT_7SLqaXeVEWY55TweFzCBtIymZ 5ElSM.nJXo6wNK_BBcKxT4Yh5GU0BLnk5whi_6mComD_chq72gvFiYM1NbaBS6MxgnsIn8t81DMz R5kTte0wzBKBVcuWcdeJ83_FnHYQn9RTaFZyb5reY6pftutXUKD8bNSSvs7b3JAFo3LSCxtDXkFU x_rMFhw80lGTA8lE532I- X-Sonic-MF: X-Sonic-ID: 904e45d7-df2d-4cd6-9a03-87ae31bf858a Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Tue, 3 Dec 2024 07:38:38 +0000 Received: by hermes--production-gq1-5dd4b47f46-ps69l (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c601e501aa9c2cd0acecd24331934546; Tue, 03 Dec 2024 07:38: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 \(3776.700.51.11.1\)) Subject: Re: Official armv7 PkgBase kernel-NODEBUG installation's USB2 boot gets "Fatal kernel mode data abort: 'Alignment Fault' on write" very early, at least on an OrangePi+ 2ed From: Mark Millard In-Reply-To: <4c29d5cb-0a31-4131-a3a9-846fd4ce926f@FreeBSD.org> Date: Mon, 2 Dec 2024 23:38:23 -0800 Cc: FreeBSD ARM List , FreeBSD-STABLE Mailing List , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: References: <74468E62-5A74-4FB4-94F6-599E5BA3A9A1@yahoo.com> <4c29d5cb-0a31-4131-a3a9-846fd4ce926f@FreeBSD.org> To: "mmel@freebsd.org" X-Mailer: Apple Mail (2.3776.700.51.11.1) 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)[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)[]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.148:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.148:from] X-Rspamd-Queue-Id: 4Y2XZm5GNpz4Lnp X-Spamd-Bar: --- Top post of identifying a new context: Now that stable/14 is based on LLVM19, stable/14 is broken like main [so: 15] was, at least in part. Some MFC activity looks to be required in order to boot armv7 via stable/14 now. More may be required. The failure looks like: . . . mmc1: on aw_mmc1 mmc1: No compatible cards found on bus aw_mmc1: Spurious interrupt - no active request, rint: 0x00000004 mmc2: on aw_mmc0 mmcsd1: 32GB at mmc2 = 50.0MHz/4bit/32768-block mmc2: Failed to set VCCQ for card at relative address 43690 uhub0: 1 port with 1 removable, self powered uhub2: 1 port with 1 removable, self powered uhub5: 1 port with 1 removable, self powered uhub8: 1 port with 1 removable, self powered Root mount waiting for: usbus3 Fatal kernel mode data abort: 'Alignment Fault' on write trapframe: 0xc6b7dc10 FSR=3D00000801, FAR=3Ddb0b901b, spsr=3D20000013 r0 =3Ddb0b9000, r1 =3D00000000, r2 =3D00000006, r3 =3D00000024 r4 =3Ddb058c80, r5 =3D00000000, r6 =3D00000001, r7 =3D00000006 r8 =3Dc6b7dd20, r9 =3Dc0b324fc, r10=3Dc08ef8dc, r11=3Dc6b7dcb8 r12=3D00000000, ssp=3Dc6b7dca0, slr=3Dc019f774, pc =3Dc019f524 panic: Fatal abort cpuid =3D 1 time =3D 3 KDB: stack backtrace: Fatal kernel mode data abort: 'Translation Fault (L1)' on read trapframe: 0xc6b7d970 FSR=3D00000005, FAR=3Da3e89ab0, spsr=3D200001d3 r0 =3Dc6b7da24, r1 =3D00000001, r2 =3Da3e89aad, r3 =3D63622c6d r4 =3Dc0866e44, r5 =3Df3bea0b1, r6 =3D0000a776, r7 =3D81000000 r8 =3Dc0813294, r9 =3Dc0b229c4, r10=3Dc6b7db1c, r11=3Dc6b7da18 r12=3Dc6b7dad8, ssp=3Dc6b7da00, slr=3Dc0665720, pc =3Dc066974c panic: Fatal abort cpuid =3D 1 time =3D 3 KDB: stack backtrace: Fatal kernel mode data abort: 'Translation Fault (L1)' on read trapframe: 0xc6b7d6f0 FSR=3D00000005, FAR=3Da3e89ab0, spsr=3D200001d3 r0 =3Dc6b7d7a4, r1 =3D00000001, r2 =3Da3e89aad, r3 =3D63622c6d r4 =3Dc0866e44, r5 =3Df3bea0b1, r6 =3D0000a776, r7 =3D81000000 r8 =3Dc0813294, r9 =3Dc0b229c4, r10=3Dc6b7d89c, r11=3Dc6b7d798 r12=3Dc6b7d858, ssp=3Dc6b7d780, slr=3Dc0665720, pc =3Dc066974c panic: Fatal abort cpuid =3D 1 time =3D 3 KDB: stack backtrace: Fatal kernel mode data abort: 'Translation Fault (L1)' on read trapframe: 0xc6b7d470 FSR=3D00000005, FAR=3Da3e89ab0, spsr=3D200001d3 r0 =3Dc6b7d524, r1 =3D00000001, r2 =3Da3e89aad, r3 =3D63622c6d r4 =3Dc0866e44, r5 =3Df3bea0b1, r6 =3D0000a776, r7 =3D81000000 r8 =3Dc0813294, r9 =3Dc0b229c4, r10=3Dc6b7d61c, r11=3Dc6b7d518 r12=3Dc6b7d5d8, ssp=3Dc6b7d500, slr=3Dc0665720, pc =3Dc066974c After that the L1 translation fault repeats over and over. On Nov 8, 2024, at 04:49, Michal Meloun wrote: > On 08.11.2024 4:15, Mark Millard wrote: >> [I narrowed the artifact kernel range for the change in the type of >> failure that happens.] >> On Nov 7, 2024, at 17:43, Mark Millard wrote: >>> [The change to LLVM 19 is what leads to the Alignment >>> Fault' on write failure. Details later below.] >>>=20 >>> On Nov 7, 2024, at 01:42, Mark Millard wrote: >>>=20 >>>> Note: Unfortunately, the panics here are too early for a >>>> dump device to be available. >>>>=20 >>>> Context started PkgBase upgrade from: >>>>=20 >>>> # uname -apKU >>>> FreeBSD OPiP2E-RPi2v1p1 15.0-CURRENT FreeBSD 15.0-CURRENT = main-n272821-37798b1d5dd1 GENERIC-NODEBUG arm armv7 1500025 1500025 >>>>=20 >>>> Installed packages to be UPGRADED: >>>> FreeBSD-dtb: 15.snap20241009161500 -> 15.snap20241028121139 = [base] >>>> FreeBSD-kernel-generic: 15.snap20241011221604 -> = 15.snap20241106134422 [base] >>>> FreeBSD-kernel-generic-dbg: 15.snap20241011221604 -> = 15.snap20241106134422 [base] >>>> FreeBSD-kernel-generic-mmccam: 15.snap20241011221604 -> = 15.snap20241106134422 [base] >>>> FreeBSD-kernel-generic-mmccam-dbg: 15.snap20241011221604 -> = 15.snap20241106134422 [base] >>>> FreeBSD-kernel-generic-nodebug: 15.snap20241011221604 -> = 15.snap20241106134422 [base] >>>> FreeBSD-kernel-generic-nodebug-dbg: 15.snap20241011221604 -> = 15.snap20241106134422 [base] >>>> FreeBSD-src-sys: 15.snap20241011221604 -> = 15.snap20241106160110 [base] >>>>=20 >>>> (Those were installed but the FreeBSD-dtb had linux 6.4 >>>> dtb files, not the 6.8 ones. 6.8 ones from a personal build >>>> were copied to where they need to be. I've separately >>>> reported the 6.4 vs. 6.8 issue.) >>>>=20 >>>> # ~/pkgbase-snapshot-list.sh >>>> Via pkg-static info -C -x '^FreeBSD-' . . . >>>> 1 FreeBSD-*-15.snap20241106160110 >>>> 6 FreeBSD-*-15.snap20241106134422 >>>> 1 FreeBSD-*-15.snap20241028121139 >>>> 3 FreeBSD-*-15.snap20241011221604 >>>> 2 FreeBSD-*-15.snap20241011210446 >>>> 38 FreeBSD-*-15.snap20241011182434 >>>> 4 FreeBSD-*-15.snap20241011073851 >>>> 5 FreeBSD-*-15.snap20241010141501 >>>> 1 FreeBSD-*-15.snap20241010120743 >>>> 296 FreeBSD-*-15.snap20241009161500 >>>> Instead via /var/cache/pkg/*.snap*.pkg . . . >>>> 1 FreeBSD-*-15.snap20241106160110 >>>> 6 FreeBSD-*-15.snap20241106134422 >>>> 1 FreeBSD-*-15.snap20241028121139 >>>> 10 FreeBSD-*-15.snap20241011221604 >>>> 2 FreeBSD-*-15.snap20241011210446 >>>> 38 FreeBSD-*-15.snap20241011182434 >>>> 4 FreeBSD-*-15.snap20241011073851 >>>> 5 FreeBSD-*-15.snap20241010141501 >>>> 1 FreeBSD-*-15.snap20241010120743 >>>> 297 FreeBSD-*-15.snap20241009161500 >>>>=20 >>>>=20 >>>> The failure (kernel-GENERIC-NODEBUG): >>>>=20 >>>> . . . >>>> Root mount waiting for: usbus3 CAM >>>> Fatal kernel mode data abort: 'Alignment Fault' on write >>>> trapframe: 0xc6c9ac10 >>>> FSR=3D00000801, FAR=3Ddb23209b, spsr=3D20000013 >>>> r0 =3Ddb232080, r1 =3D00000000, r2 =3D00000006, r3 =3D00000024 >>>> r4 =3Ddb19e280, r5 =3D00000000, r6 =3D00000001, r7 =3D00000006 >>>> r8 =3Dc6c9ad20, r9 =3Dc0b7973c, r10=3Dc092074c, r11=3Dc6c9acb8 >>>> r12=3D00000000, ssp=3Dc6c9aca0, slr=3Dc01b01d8, pc =3Dc01aff88 >>>>=20 >>>> panic: Fatal abort >>>> cpuid =3D 1 >>>> time =3D 3 >>>> KDB: stack backtrace: >>>> db_trace_self() at db_trace_self >>>> pc =3D 0xc0667004 lr =3D 0xc0078630 = (db_trace_self_wrapper+0x30) >>>> sp =3D 0xc6c9a9c8 fp =3D 0xc6c9aae0 >>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x30 >>>> pc =3D 0xc0078630 lr =3D 0xc0328db8 (vpanic+0x140) >>>> sp =3D 0xc6c9aae8 fp =3D 0xc6c9ab08 >>>> r4 =3D 0x00000100 r5 =3D 0x00000000 >>>> r6 =3D 0xc084d1f1 r7 =3D 0xc0b69a94 >>>> vpanic() at vpanic+0x140 >>>> pc =3D 0xc0328db8 lr =3D 0xc0328c78 (vpanic) >>>> sp =3D 0xc6c9ab10 fp =3D 0xc6c9ab14 >>>> r4 =3D 0xc6c9ac10 r5 =3D 0x00000013 >>>> r6 =3D 0xdb23209b r7 =3D 0x00000001 >>>> r8 =3D 0x00000801 r9 =3D 0x00000013 >>>> r10 =3D 0xdb23209b >>>> vpanic() at vpanic >>>> pc =3D 0xc0328c78 lr =3D 0xc068c8e8 (abort_align) >>>> sp =3D 0xc6c9ab1c fp =3D 0xc6c9ab48 >>>> r4 =3D 0x00000001 r5 =3D 0x00000801 >>>> r6 =3D 0x00000013 r7 =3D 0xdb23209b >>>> r8 =3D 0xc6c9ab14 r9 =3D 0xc0328c78 >>>> r10 =3D 0xc6c9ab1c >>>> abort_align() at abort_align >>>> pc =3D 0xc068c8e8 lr =3D 0xc068c958 (abort_align+0x70) >>>> sp =3D 0xc6c9ab50 fp =3D 0xc6c9ab68 >>>> r4 =3D 0xc6d21c00 r10 =3D 0xdb23209b >>>> abort_align() at abort_align+0x70 >>>> pc =3D 0xc068c958 lr =3D 0xc068c5e0 (abort_handler+0x430) >>>> sp =3D 0xc6c9ab70 fp =3D 0xc6c9ac08 >>>> r4 =3D 0x00000000 r10 =3D 0xdb23209b >>>> abort_handler() at abort_handler+0x430 >>>> pc =3D 0xc068c5e0 lr =3D 0xc0669868 (exception_exit) >>>> sp =3D 0xc6c9ac10 fp =3D 0xc6c9acb8 >>>> r4 =3D 0xdb19e280 r5 =3D 0x00000000 >>>> r6 =3D 0x00000001 r7 =3D 0x00000006 >>>> r8 =3D 0xc6c9ad20 r9 =3D 0xc0b7973c >>>> r10 =3D 0xc092074c >>>> exception_exit() at exception_exit >>>> pc =3D 0xc0669868 lr =3D 0xc01b01d8 = (usb_msc_auto_quirk+0xfc) >>>> sp =3D 0xc6c9aca0 fp =3D 0xc6c9acb8 >>>> r0 =3D 0xdb232080 r1 =3D 0x00000000 >>>> r2 =3D 0x00000006 r3 =3D 0x00000024 >>>> r4 =3D 0xdb19e280 r5 =3D 0x00000000 >>>> r6 =3D 0x00000001 r7 =3D 0x00000006 >>>> r8 =3D 0xc6c9ad20 r9 =3D 0xc0b7973c >>>> r10 =3D 0xc092074c r12 =3D 0x00000000 >>>> bbb_command_start() at bbb_command_start+0x4c >>>> pc =3D 0xc01aff88 lr =3D 0xc01b01d8 = (usb_msc_auto_quirk+0xfc) >>>> sp =3D 0xc6c9acc0 fp =3D 0xc6c9acf8 >>>> r4 =3D 0xdb16d800 r5 =3D 0xdb19e280 >>>> r6 =3D 0x00000001 r10 =3D 0xc092074c >>>> usb_msc_auto_quirk() at usb_msc_auto_quirk+0xfc >>>> pc =3D 0xc01b01d8 lr =3D 0xc01a4bd8 = (usb_alloc_device+0x9c4) >>>> sp =3D 0xc6c9ad00 fp =3D 0xc6c9ad68 >>>> r4 =3D 0x00000000 r5 =3D 0x00000001 >>>> r6 =3D 0x00000000 r7 =3D 0x00000002 >>>> r8 =3D 0xdb16d800 r9 =3D 0xda241c78 >>>> r10 =3D 0x000003ee >>>> usb_alloc_device() at usb_alloc_device+0x9c4 >>>> pc =3D 0xc01a4bd8 lr =3D 0xc01ad16c (uhub_explore+0x494) >>>> sp =3D 0xc6c9ad70 fp =3D 0xc6c9adc0 >>>> r4 =3D 0x00000000 r5 =3D 0x00000000 >>>> r6 =3D 0xdb16e800 r7 =3D 0x00000000 >>>> r8 =3D 0xdb18c200 r9 =3D 0x00000001 >>>> r10 =3D 0x00000000 >>>> uhub_explore() at uhub_explore+0x494 >>>> pc =3D 0xc01ad16c lr =3D 0xc0198654 (usb_bus_explore+0x1d4) >>>> sp =3D 0xc6c9adc8 fp =3D 0xc6c9add8 >>>> r4 =3D 0xda241c78 r5 =3D 0xdb16e800 >>>> r6 =3D 0x00000000 r7 =3D 0xda241d6c >>>> r8 =3D 0xc09b0b5f r9 =3D 0x00000001 >>>> r10 =3D 0xda241d1c >>>> usb_bus_explore() at usb_bus_explore+0x1d4 >>>> pc =3D 0xc0198654 lr =3D 0xc01b22d0 (usb_process+0x124) >>>> sp =3D 0xc6c9ade0 fp =3D 0xc6c9ae10 >>>> r4 =3D 0xda241d0c r5 =3D 0xda241d14 >>>> usb_process() at usb_process+0x124 >>>> pc =3D 0xc01b22d0 lr =3D 0xc02da4f0 (fork_exit+0xb0) >>>> sp =3D 0xc6c9ae18 fp =3D 0xc6c9ae38 >>>> r4 =3D 0xc6c9ae40 r5 =3D 0xc6d21c00 >>>> r6 =3D 0xc6d08740 r7 =3D 0xda241d0c >>>> r8 =3D 0xc01b21ac r9 =3D 0x00000000 >>>> r10 =3D 0x00000000 >>>> fork_exit() at fork_exit+0xb0 >>>> pc =3D 0xc02da4f0 lr =3D 0xc06697fc (swi_exit) >>>> sp =3D 0xc6c9ae40 fp =3D 0x00000000 >>>> r4 =3D 0xc01b21ac r5 =3D 0xda241d0c >>>> r6 =3D 0x00000000 r7 =3D 0x00000000 >>>> r8 =3D 0x00000000 r10 =3D 0x00000000 >>>> swi_exit() at swi_exit >>>> pc =3D 0xc06697fc lr =3D 0xc06697fc (swi_exit) >>>> sp =3D 0xc6c9ae40 fp =3D 0x00000000 >>>> KDB: enter: panic >>>> [ thread pid 14 tid 100069 ] >>>> Stopped at kdb_enter+0x54: ldrb r15, [r15, r15, ror r15]! >>>> db> >>>=20 >>> Using just available official artifact kernels for testing >>> I've established that 0953460ce149 (and various from before >>> that) does not have the problem: >>>=20 >>> Wed, 23 Oct 2024 >>> =E2=80=A2 git: 5c92f84bb607 - main - LinuxKPI: update = rcu_dereference_*() and lockdep_is_held() Bjoern A. Zeeb >>> =E2=80=A2 git: 6fa91acca40d - main - conf/NOTES: Remove trailing = whitespace Li-Wen Hsu >>> =E2=80=A2 git: 91b7b225b2ce - main - LINT: Add mac_do Li-Wen Hsu >>> =E2=80=A2 git: 419249c1cacc - main - Revert "LINT: Add mac_do" = Li-Wen Hsu >>> =E2=80=A2 Re: git: 419249c1cacc - main - Revert "LINT: Add = mac_do" Baptiste Daroussin >>> =E2=80=A2 Re: git: 13da1af1cd67 - main - libcxxrt: Update to = upstream 698997bfde1f John Baldwin >>> =E2=80=A2 Re: git: 419249c1cacc - main - Revert "LINT: Add = mac_do" John Baldwin >>> =E2=80=A2 git: 0953460ce149 - main - libc: fix access mode tests = in fmemopen(3) Ed Maste >>>=20 >>> So the above one worked. >>>=20 >>> The next available kernel to test was f3dbef108212 (the bump for = LLVM19 >>> at the end of the below): >>>=20 >>> =E2=80=A2 RE: git: 6a07e67fb7a8 - main - vm_meter: Fix laundry = accounting Mark Millard >>> =E2=80=A2 git: 6b9f7133aba4 - main - libc: Add one more check in = new fmemopen test Ed Maste >>> =E2=80=A2 git: 0fca6ea1d4ee - main - Merge llvm-project main = llvmorg-19-init-18630-gf2ccf80136a0 Dimitry Andric >>> =E2=80=A2 git: 36b606ae6aa4 - main - Merge llvm-project = release/19.x llvmorg-19.1.0-rc1-0-ga4902a36d5c2 Dimitry Andric >>> =E2=80=A2 git: 3f157662c0ef - main - Tentatively apply = https://github.com/llvm/llvm-project/pull/101403 Dimitry Andric >>> =E2=80=A2 git: d575077527d4 - main - bsd.sys.mk: for clang >=3D = 19, similar to gcc >=3D 8.1, turn off -Werror for = -Wcast-function-type-mismatch. Dimitry Andric >>> =E2=80=A2 git: 36d486cc2ecd - main - Fix enum warning in = ath_hal's ar9002 Dimitry Andric >>> =E2=80=A2 git: 6846ab2fb663 - main - libcxx simd_utils.h: only = enable _LIBCPP_HAS_ALGORITHM_VECTOR_UTILS for clang >=3D 15, since older = versions do not support the required builtins. Dimitry Andric >>> =E2=80=A2 git: 81e300df5e65 - main - libcxx atomic_ref.h: add = typename keyword for difference_type declarations, otherwise older clang = versions cannot compile this header. Dimitry Andric >>> =E2=80=A2 git: 6b4981df6008 - main - libcxx cstdlib, cwchar: = avoid using long long functions if not supported, even for older = compilers that do not support the using_if_exists attribute. Dimitry = Andric >>> =E2=80=A2 git: 2f6d6eaf2d51 - main - libcxx-compat: revert = llvmorg-19-init-18063-g561246e90282: Dimitry Andric >>> =E2=80=A2 git: 04f5b79cfa49 - main - libcxx-compat: revert = llvmorg-19-init-18062-g4dfa75c663e5: Dimitry Andric >>> =E2=80=A2 git: e8054e44f4ca - main - libcxx-compat: revert = llvmorg-19-init-17853-g578c6191eff7: Dimitry Andric >>> =E2=80=A2 git: 0bec0529b1d7 - main - libcxx-compat: revert = llvmorg-19-init-17728-g30cc12cd818d: Dimitry Andric >>> =E2=80=A2 git: e8847079df1b - main - libcxx-compat: revert = llvmorg-19-init-17727-g0eebb48fcfbc: Dimitry Andric >>> =E2=80=A2 git: 2f2ebe758bea - main - libcxx-compat: revert = llvmorg-19-init-17473-g69fecaa1a455: Dimitry Andric >>> =E2=80=A2 git: 1199d38d8ec7 - main - libcxx-compat: revert = llvmorg-19-init-8667-g472b612ccbed: Dimitry Andric >>> =E2=80=A2 git: a7b2d7f261b8 - main - libcxx-compat: revert = llvmorg-19-init-5639-ga10aa4485e83: Dimitry Andric >>> =E2=80=A2 git: f3859a1a13a1 - main - libcxx-compat: revert = llvmorg-19-init-4504-g937a5396cf3e: Dimitry Andric >>> =E2=80=A2 git: 072b5fb698ab - main - libcxx-compat: revert = llvmorg-19-init-4003-g55357160d0e1: Dimitry Andric >>> =E2=80=A2 git: b60301d8b594 - main - libcxx-compat: don't remove = headers that were reintroduced by reverts Dimitry Andric >>> =E2=80=A2 git: 2e861daab905 - main - libcxx-compat: install = headers that were reintroduced by reverts Dimitry Andric >>> =E2=80=A2 git: ff6c8447844b - main - libcxx-compat: update = libcxx.imp for headers that were reintroduced by reverts Dimitry Andric >>> =E2=80=A2 git: 52418fc2be8e - main - Merge llvm-project = release/19.x llvmorg-19.1.0-rc2-0-gd033ae172d1c Dimitry Andric >>> =E2=80=A2 git: 62987288060f - main - Merge llvm-project = release/19.x llvmorg-19.1.0-rc3-0-g437434df21d8 Dimitry Andric >>> =E2=80=A2 git: 6c4b055cfb6b - main - Merge llvm-project = release/19.x llvmorg-19.1.0-rc4-0-g0c641568515a Dimitry Andric >>> =E2=80=A2 git: 835c3a3e69af - main - Merge commit 6dbdb8430b49 = from llvm git (by Nikolas Klauser): Dimitry Andric >>> =E2=80=A2 git: c80e69b00d97 - main - Merge llvm-project = release/19.x llvmorg-19.1.0-0-ga4bf6cd7cfb1 Dimitry Andric >>> =E2=80=A2 git: 6e516c87b6d7 - main - Merge llvm-project = release/19.x llvmorg-19.1.1-0-gd401987fe349 Dimitry Andric >>> =E2=80=A2 git: 5deeebd8c6ca - main - Merge llvm-project = release/19.x llvmorg-19.1.2-0-g7ba7d8e2f7b6 Dimitry Andric >>> =E2=80=A2 git: f3dbef108212 - main - Bump __FreeBSD_version for = llvm 19.1.2 merge Dimitry Andric >>>=20 >>> f3dbef108212 gets the: >>>=20 >>> "Fatal kernel mode data abort: 'Alignment Fault' on write" >>>=20 >>> boot failure for artifact kernel. 6b9f7133aba4 does nit >>> seem a likely source of the problem, basically leaving the >>> LLVM changes as what is at issue. >>>=20 >>> I'll note that artifact kernels are witness kernels. So >>> this exploration adds to the distinctions observed >>> compared to the prior notes. >>>=20 >>>> Looking at bbb_command_start() 's pc: >>>>=20 >>>> # llvm-addr2line -e /boot/kernel.GENERIC-NODEBUG/kernel 0xc01aff88 >>>> /home/pkgbuild/worktrees/main/sys/dev/usb/usb_msctest.c:554 >>>>=20 >>>> What leads to that line is: >>>>=20 >>>> = /*------------------------------------------------------------------------= * >>>> * bbb_command_start - execute a SCSI command synchronously >>>> * >>>> * Return values >>>> * 0: Success >>>> * Else: Failure >>>> = *------------------------------------------------------------------------*= / >>>> static int >>>> bbb_command_start(struct bbb_transfer *sc, uint8_t dir, uint8_t = lun, >>>> void *data_ptr, size_t data_len, void *cmd_ptr, size_t cmd_len, >>>> usb_timeout_t data_timeout) >>>> { >>>> sc->lun =3D lun; >>>> sc->dir =3D data_len ? dir : DIR_NONE; >>>> sc->data_ptr =3D data_ptr; >>>> sc->data_len =3D data_len; >>>> sc->data_rem =3D data_len; >>>> sc->data_timeout =3D (data_timeout + USB_MS_HZ); >>>> sc->actlen =3D 0; >>>> sc->error =3D 0; >>>> sc->cmd_len =3D cmd_len; >>>> memset(&sc->cbw->CBWCDB, 0, sizeof(sc->cbw->CBWCDB)); >>>>=20 >>>> The memset line is line 554 of sys/dev/usb/usb_msctest.c . >>>=20 >>> The below looks to be a separate problem based on >>> some later FreeBSD kernel update than the above. >>>=20 >>>> I'll note that attempting to use the WITNESS variant of the kernel >>>> ( /boot/kernel/ ) gets a different, even earlier failure: >>>>=20 >>>> . . . >>>> VT: init without driver. >>>> panic: acquiring blockable sleep lock with spinlock or critical = section held (sleep mutex) pmap @ = /home/pkgbuild/worktrees/main/sys/arm/arm/pmap-v6.c:6455 >>>=20 >>> I do know that d021d3b3c675 at the end of the below >>> shows this failure --before the system has a chance >>> to get the usb related write alignment failure >>> reported above. >>>=20 >>> I have not explored where in the below range the >>> behavior changes (for what is available as an >>> official artifact kernel). It seems unlikely that >>> any of the below would actually boot: it is likely >>> a question of which of the 2 (or more) failure >>> types happen for each instead. >> The last before "Thu, 24, Oct 2024" was: >> =E2=80=A2 git: 8b2e7da70855 - main - llvm19: permit = incremental builds from llvm18 Brooks Davis >> That is the last available artifact kernel that gets the >> original usb related write alignment type of failure. >>> Thu, 24 Oct 2024 >>> =E2=80=A2 git: 34951b0b9e78 - main - swap_pager: move = scan_all_shadowed, use iterators Doug Moore >>> =E2=80=A2 git: 2ac21f2c98ed - main - x86 specialreg.h: visually = align %cr4 and MSR_EFER bit mask definitions Konstantin Belousov >>> =E2=80=A2 git: cc11bc1150d5 - main - x86 specialreg.h: add all = defined bits for %cr4 Konstantin Belousov >>> =E2=80=A2 git: cc4b25f10211 - main - x86 specialreg: reorder %cr3 = bits masks definitions by value Konstantin Belousov >>> =E2=80=A2 git: 5999b74e9637 - main - x86 specialreg: add bit = masks definitions for LAM in %cr3 Konstantin Belousov >>> =E2=80=A2 git: 6308db659f2a - main - x86 specialreg: add bit = masks definitions for EFER features Konstantin Belousov >>> =E2=80=A2 git: 9f718b57b846 - main - x86 specialreg: add bit = masks definitions for LASS and LAM features Konstantin Belousov >>> =E2=80=A2 git: 3360a15898ce - main - net: route: convert routing = statistics to a sysctl Kyle Evans >>> =E2=80=A2 Re: git: 3360a15898ce - main - net: route: convert = routing statistics to a sysctl Kyle Evans >>> =E2=80=A2 git: 77b70ad751df - main - e1000: Move I219 LM19/V19 to = ADL Kevin Bowling >> The last above is the first available artifact kernel that >> that gets the different error. There are no armv7 artifact >> kernels between 8b2e7da70855 and 77b70ad751df . >> So something from 34951b0b9e78 .. 77b70ad751df leads to >> the change in the type of failure. I've no clue what. >> It looked to me like the x86 commits and e1000 commit had >> no chance of contributing to the armv7 context. Thus >> who I added to the CC vs. did not add. >>> =E2=80=A2 git: d64442a89896 - main - arm{,64}: use genassym for = INTR_ROOT_* values Kyle Evans >>> =E2=80=A2 git: 536c8d948e85 - main - intrng: change = multi-interrupt root support type to enum Kyle Evans >>> =E2=80=A2 git: 4f12b529f404 - main - sys/intr.h: formally depend = on machine/intr.h Kyle Evans >>> =E2=80=A2 git: a5b1eecbed07 - main - Apply workaround for = building llvm-project with WITHOUT_LLVM_ASSERTIONS Dimitry Andric >>> =E2=80=A2 git: 1c83996beda7 - main - Adjust = LLVM_ENABLE_ABI_BREAKING_CHECKS depending on NDEBUG Dimitry Andric >>> =E2=80=A2 git: b2dd4970c7b5 - main - dev/gpio: Mask all pl011 = interrupts Andrew Turner >>> =E2=80=A2 git: 3b03e1bb8615 - main - intrng: Store the IPI = priority Andrew Turner >>> =E2=80=A2 git: 6204391e99ca - main - arm64: Check TDP_NOFAULTING = in a data abort Andrew Turner >>> =E2=80=A2 git: a84653c5db25 - main - arm64: Don't enable = interrupts when in a spinlock Andrew Turner >>> =E2=80=A2 git: d7f930b80e89 - main - arm64: Implement = efi_rt_arch_call Andrew Turner >>> =E2=80=A2 git: 8efb1500d4f1 - main - arm64: Enable handling EFI = runtime service faults Andrew Turner >>> =E2=80=A2 git: 9693241188aa - main - sound: Call DSP_REGISTERED = before PCM_DETACHING Christos Margiolis >>> =E2=80=A2 git: bb5e3ac1a7b7 - main - sound: Use DSP_REGISTERED in = dsp_clone() Christos Margiolis >>> =E2=80=A2 git: a4111e9dc722 - main - sound: Change PCMDIR_* = numbering Christos Margiolis >>> =E2=80=A2 git: 802c78f5194e - main - sound: Untangle dsp_cdevs[] = and dsp_unit2name() confusion Christos Margiolis >>> =E2=80=A2 git: b1bb6934bb87 - main - sound: Fix build error in = chm_mkname() KASSERT Christos Margiolis >>> =E2=80=A2 git: ce20b48a60fb - main - sctp: improve debug output = Michael Tuexen >>> =E2=80=A2 git: e4ac0183a1a8 - main - sctp: cleanup Michael Tuexen >>> =E2=80=A2 git: 8c8ebbb04518 - main - bhyve ahci: Improve = robustness of TRIM handling John Baldwin >>> =E2=80=A2 git: f0bc751d6fb4 - main - csa: Use pci_find_device to = simplify clkrun_hack John Baldwin >>> =E2=80=A2 git: d96ba5a62365 - main - config: Remove a stray = semicolon Zhenlei Huang >>> =E2=80=A2 git: 56b17de1e836 - main - makefs: Remove a stray = semicolon Zhenlei Huang >>> =E2=80=A2 git: 88b71d1fe054 - main - arm64: rockchip: Remove a = stray semicolon Zhenlei Huang >>> =E2=80=A2 git: b4856b8e9d87 - main - LinuxKPI: Remove stray = semicolons Zhenlei Huang >>> =E2=80=A2 git: 75ff90814aec - main - enic: Remove a stray = semicolon Zhenlei Huang >>> =E2=80=A2 git: 6ccf4f4071c5 - main - mana: Remove stray = semicolons Zhenlei Huang >>> =E2=80=A2 git: 86a2c910c05c - main - mpi3mr: Remove a stray = semicolon Zhenlei Huang >>> =E2=80=A2 git: 36756195a342 - main - ocs_fc: Remove a stray = semicolon Zhenlei Huang >>> =E2=80=A2 git: 2f395cfda8b5 - main - tcp cc: Remove a stray = semicolon Zhenlei Huang >>> =E2=80=A2 git: f3a097d0312c - main - netstat: switch to using the = sysctl-exported stats for live stats Kyle Evans >>> =E2=80=A2 git: 656991b0c629 - main - locks: augment lock_class = with lc_trylock method Gleb Smirnoff >>> =E2=80=A2 git: efcb2ec8cb81 - main - callout: provide = CALLOUT_TRYLOCK flag Gleb Smirnoff >>> =E2=80=A2 git: bffebc336f4e - main - tcp: use CALLOUT_TRYLOCK for = the TCP callout Gleb Smirnoff >>> =E2=80=A2 git: d021d3b3c675 - main - tcp: get rid of = TDP_INTCPCALLOUT Gleb Smirnoff >>>> cpuid =3D 0 >>>> time =3D 1 >>>> KDB: stack backtrace: >>>> Fatal kernel mode data abort: 'Translation Fault (L1)' on read >>>> trapframe: 0xc0f14568 >>>> FSR=3D00000005, FAR=3Ddb7fcfb1, spsr=3D200001d3 >>>> r0 =3Dc0f1465c, r1 =3D00000001, r2 =3Ddb7fcfae, r3 =3D1b000a4e >>>> r4 =3Dc07fc55c, r5 =3D8fce1b89, r6 =3D00006f3e, r7 =3D81000000 >>>> r8 =3Dc07c4b6c, r9 =3Dc094ace8, r10=3Dc09741d8, r11=3Dc0f14618 >>>> r12=3Dc0f146c4, ssp=3Dc0f145fc, slr=3Dc0601428, pc =3Dc062686c >>>>=20 >>>> panic: Fatal abort >>>> cpuid =3D 0 >>>> time =3D 1 >>>> KDB: stack backtrace: >>>> Fatal kernel mode data abort: 'Translation Fault (L1)' on read >>>> trapframe: 0xc0f141f0 >>>> FSR=3D00000005, FAR=3Ddb7fcfb1, spsr=3D200001d3 >>>> r0 =3Dc0f142e4, r1 =3D00000001, r2 =3Ddb7fcfae, r3 =3D1b000a4e >>>> r4 =3Dc07fc55c, r5 =3D8fce1b89, r6 =3D00006f3e, r7 =3D81000000 >>>> r8 =3Dc07c4b6c, r9 =3Dc094ace8, r10=3Dc09741d8, r11=3Dc0f142a0 >>>> r12=3Dc0f1434c, ssp=3Dc0f14284, slr=3Dc0601428, pc =3Dc062686c >>>>=20 >>>> panic: Fatal abort >>>> cpuid =3D 0 >>>> time =3D 1 >>>> KDB: stack backtrace: >>>> Fatal kernel mode data abort: 'Translation Fault (L1)' on read >>>> trapframe: 0xc0f13e78 >>>> FSR=3D00000005, FAR=3Ddb7fcfb1, spsr=3D200001d3 >>>> r0 =3Dc0f13f6c, r1 =3D00000001, r2 =3Ddb7fcfae, r3 =3D1b000a4e >>>> r4 =3Dc07fc55c, r5 =3D8fce1b89, r6 =3D00006f3e, r7 =3D81000000 >>>> r8 =3Dc07c4b6c, r9 =3Dc094ace8, r10=3Dc09741d8, r11=3Dc0f13f28 >>>> r12=3Dc0f13fd4, ssp=3Dc0f13f0c, slr=3Dc0601428, pc =3Dc062686c >>>>=20 >>>> panic: Fatal abort >>>> cpuid =3D 0 >>>> time =3D 1 >>>> KDB: stack backtrace: >>>> Fatal kernel mode data abort: 'Translation Fault (L1)' on read >>>> trapframe: 0xc0f13b00 >>>> FSR=3D00000005, FAR=3Ddb7fcfb1, spsr=3D200001d3 >>>> r0 =3Dc0f13bf4, r1 =3D00000001, r2 =3Ddb7fcfae, r3 =3D1b000a4e >>>> r4 =3Dc07fc55c, r5 =3D8fce1b89, r6 =3D00006f3e, r7 =3D81000000 >>>> r8 =3Dc07c4b6c, r9 =3Dc094ace8, r10=3Dc09741d8, r11=3Dc0f13bb0 >>>> r12=3Dc0f13c5c, ssp=3Dc0f13b94, slr=3Dc0601428, pc =3Dc062686c >>>>=20 >>>> panic: Fatal abort >>>> cpuid =3D 0 >>>> time =3D 1 >>>> KDB: stack backtrace: >>>> Fatal kernel mode data abort: 'Translation Fault (L1)' on read >>>> trapframe: 0xc0f13788 >>>> FSR=3D00000005, FAR=3Ddb7fcfb1, spsr=3D200001d3 >>>> r0 =3Dc0f1387c, r1 =3D00000001, r2 =3Ddb7fcfae, r3 =3D1b000a4e >>>> r4 =3Dc07fc55c, r5 =3D8fce1b89, r6 =3D00006f3e, r7 =3D81000000 >>>> r8 =3Dc07c4b6c, r9 =3Dc094ace8, r10=3Dc09741d8, r11=3Dc0f13838 >>>> r12=3Dc0f138e4, ssp=3Dc0f1381c, slr=3Dc0601428, pc =3Dc062686c >>>>=20 >>>> . . . >>>>=20 >>>> Looking: >>>>=20 >>>> # llvm-addr2line -e /boot/kernel.GENERIC-NODEBUG/kernel 0xc062686c >>>> /home/pkgbuild/worktrees/main/sys/vm/uma_core.c:5676 >>>>=20 >>>> static int >>>> sysctl_handle_uma_zone_frees(SYSCTL_HANDLER_ARGS) >>>> { >>>> uma_zone_t zone =3D arg1; >>>> uint64_t cur; >>>>=20 >>>> cur =3D uma_zone_get_frees(zone); >>>> return (sysctl_handle_64(oidp, &cur, 0, req)); >>>> } >>>>=20 >>>> The "return" line is 5676 of sys/vm/uma_core.c . >>>>=20 >>>>=20 >>>> Also, for what leads up to: >>>>=20 >>>> /home/pkgbuild/worktrees/main/sys/arm/arm/pmap-v6.c:6455 >>>>=20 >>>> /* >>>> * The implementation of pmap_fault() uses IN_RANGE2() macro which >>>> * depends on the fact that given range size is a power of 2. >>>> */ >>>> CTASSERT(powerof2(NB_IN_PT1)); >>>> CTASSERT(powerof2(PT2MAP_SIZE)); >>>>=20 >>>> #define IN_RANGE2(addr, start, size) \ >>>> ((vm_offset_t)(start) =3D=3D ((vm_offset_t)(addr) & ~((size) - = 1))) >>>>=20 >>>> /* >>>> * Handle access and R/W emulation faults. >>>> */ >>>> int >>>> pmap_fault(pmap_t pmap, vm_offset_t far, uint32_t fsr, int idx, = bool usermode) >>>> { >>>> pt1_entry_t *pte1p, pte1; >>>> pt2_entry_t *pte2p, pte2; >>>>=20 >>>> if (pmap =3D=3D NULL) >>>> pmap =3D kernel_pmap; >>>>=20 >>>> /* >>>> * In kernel, we should never get abort with FAR which is in = range of >>>> * pmap->pm_pt1 or PT2MAP address spaces. If it happens, stop = here >>>> * and print out a useful abort message and even get to the = debugger >>>> * otherwise it likely ends with never ending loop of aborts. >>>> */ >>>> if (__predict_false(IN_RANGE2(far, pmap->pm_pt1, NB_IN_PT1))) = { >>>> /* >>>> * All L1 tables should always be mapped and present. >>>> * However, we check only current one herein. For = user mode, >>>> * only permission abort from malicious user is not = fatal. >>>> * And alignment abort as it may have higher = priority. >>>> */ >>>> if (!usermode || (idx !=3D FAULT_ALIGN && idx !=3D = FAULT_PERM_L2)) { >>>> CTR4(KTR_PMAP, "%s: pmap %#x pm_pt1 %#x far = %#x", >>>> __func__, pmap, pmap->pm_pt1, far); >>>> panic("%s: pm_pt1 abort", __func__); >>>> } >>>> return (KERN_INVALID_ADDRESS); >>>> } >>>> if (__predict_false(IN_RANGE2(far, PT2MAP, PT2MAP_SIZE))) { >>>> /* >>>> * PT2MAP should be always mapped and present in = current >>>> * L1 table. However, only existing L2 tables are = mapped >>>> * in PT2MAP. For user mode, only L2 translation = abort and >>>> * permission abort from malicious user is not fatal. >>>> * And alignment abort as it may have higher = priority. >>>> */ >>>> if (!usermode || (idx !=3D FAULT_ALIGN && >>>> idx !=3D FAULT_TRAN_L2 && idx !=3D = FAULT_PERM_L2)) { >>>> CTR4(KTR_PMAP, "%s: pmap %#x PT2MAP %#x far = %#x", >>>> __func__, pmap, PT2MAP, far); >>>> panic("%s: PT2MAP abort", __func__); >>>> } >>>> return (KERN_INVALID_ADDRESS); >>>> } >>>>=20 >>>> /* >>>> * A pmap lock is used below for handling of access and R/W = emulation >>>> * aborts. They were handled by atomic operations before so = some >>>> * analysis of new situation is needed to answer the = following question: >>>> * Is it safe to use the lock even for these aborts? >>>> * >>>> * There may happen two cases in general: >>>> * >>>> * (1) Aborts while the pmap lock is locked already - this = should not >>>> * happen as pmap lock is not recursive. However, under pmap = lock only >>>> * internal kernel data should be accessed and such data = should be >>>> * mapped with A bit set and NM bit cleared. If double abort = happens, >>>> * then a mapping of data which has caused it must be fixed. = Further, >>>> * all new mappings are always made with A bit set and the = bit can be >>>> * cleared only on managed mappings. >>>> * >>>> * (2) Aborts while another lock(s) is/are locked - this = already can >>>> * happen. However, there is no difference here if it's = either access or >>>> * R/W emulation abort, or if it's some other abort. >>>> */ >>>>=20 >>>> PMAP_LOCK(pmap); >>>>=20 >>>> That "PMAP_LOCK(pmap);" line is line 6455 of sys/arm/arm/pmap-v6.c = . >>>>=20 >>>>=20 >>>> FYI: Running the prior kernel.GENERIC-NODEBUG/ ( called >>>> kernel.GENERIC-NODEBUG.good/ ) continues to operate >>>> normally. I do not have the older PkgBase kernel/ around >>>> to try, unfortunately. >> I'll remind that this is from using official FreeBSD builds >> of the kernel versions that I tested, not from my personal >> build context. >> =3D=3D=3D >> Mark Millard >> marklmi at yahoo.com > Hi Mark, >=20 > Please see https://reviews.freebsd.org/D47485 >=20 > Unfortunately, I see 2 problems with llvm 19. >=20 > The first is regression, the compiler generates inline memset() = accessing non-aligned data with sub-optimal instructions (with word = access). This regression triggers bug in the kernel (which should be = fixed in D47485). >=20 > Second, regarding "panic: acquiring blockable sleep lock" is due to an = bug in lld. It mis-links the ".ARM.exidx" section on the output = binary, which is used by the stack unwinder in the kernel. > I don't have a fix for this for now, so you have to use the linker = from llvm18 as a workaround. >=20 > I'm not sure if I have enough free cycles to manage both issues on the = llvm side... =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Dec 4 14:06:19 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Y3K7c2NNmz5fdY3 for ; Wed, 04 Dec 2024 14:06: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 "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Y3K7c0Hm9z4MXj for ; Wed, 4 Dec 2024 14:06:20 +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=1733321180; 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=frERCmOHShjI8aGmQ7SNI6XSCFlmXnuOKGGwmmbQPg4=; b=ZJtGe1aUmg4EQbC/P+WDr+MMsfkSAjzHpAxQwV02Y9XZ+d6tCHEqztWVNzvRmmcxbNVJ7k 4KqJPPm5kgIed+ehdkOaQDL+58jIE07SkRE99GRYs5634nuixL3rEDYP1zMUpgS6dJIySY RYaPUVjRvt1J75WFVGZ3K1VWAhLpe86yIZWP9gD8hhdaER2asTS5/82ZD+Up6yuL42vBNy nkYcsRwoyKbbAxQseUKGoD4RaeBcvOSH6yU8UG+vI8scmvOUb2H4nNPfBBSYTIzMQ29Ame 6rzMFusgPlj5L48/fCTG03oz7wyNbN5Vx4OP0WGSfaqzfXIHbMOdDT9YGHnPOg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1733321180; a=rsa-sha256; cv=none; b=Qc8a1iz95DPs04AwcTAiyN0FfGn57mMUP9vCYSRBwJXMOyPtqqkugYbgjYUtBPESH3PcMv TFYyUW5Wcx0SeQsDhVpxb7lk7xId/1AolmDdaCE6a3yNzGPMns8XQ9yTuTM4kp6A+2hU00 XTe7e5Rr/uRTKwoCPc8qc/Wu1oJlMmA8IKfcoT8Xe8fRDRPNyvm/OdEMeMHfU1M/WZXXrx LH1bmwWpLGm1f+5cvK2IqMq2nCNH570lBXtHAnudod5pBGOWCg+s/FGllU5bw2bVRQA6FZ 5wIBcadsTJN0ZB4nVmOF2d50IDXR0UhANYbuV/q+5k/1WzXaRsLsV46IJdM2Dg== 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 4Y3K7b6swLz19HN for ; Wed, 4 Dec 2024 14:06: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 4B4E6JkW099697 for ; Wed, 4 Dec 2024 14:06:19 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 4B4E6JEH099696 for freebsd-arm@FreeBSD.org; Wed, 4 Dec 2024 14:06: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 261948] [boot] Loop of "Root mount waiting for: usbus0 CAM" on Oracle OCI Cloud Ampere A1 Compute instance Date: Wed, 04 Dec 2024 14:06: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: 13.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: dch@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Unable to Reproduce X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D261948 Dave Cottlehuber changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |Unable to Reproduce Status|Open |Closed --- Comment #11 from Dave Cottlehuber --- hi Yonas thanks for reporting this, but I can't reproduce this without more info. I'm closing this for the moment, but please re-open if you can reproduce it with specific shape & config. As we now have FreeBSD images in the Oracle Marketplace, can you please check using those and report back *specifically* what shape/config/tunables gives this issue. https://cloudmarketplace.oracle.com/marketplace/app/freebsd-release thanks! --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Thu Dec 5 02:35:24 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Y3dmF6cFNz5fgDm for ; Thu, 05 Dec 2024 02:35:41 +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 4Y3dmC4K0Sz4sV1 for ; Thu, 5 Dec 2024 02:35:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=WDc2eijt; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.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=1733366137; bh=PQH2MSTXNipAouTxwitPbeIrYJiOTDfa6Eb9QtFY6gA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=WDc2eijtyLwvswyeIr3HtmYBDI9vZ/aOMU3cXV/N5aAju3/Nb5VXU1O9q9P/qh+JTCH59I27TK7nDinegLAMWL/SyWH7iuD1GvNmEEhm0LkzcoJ1K3Pd7cpiB35EyfMDgaDjc5DLvkZFMDqRuXjjTKeydM9EEAcZ53hY/wwNyr/bQCbiwHbBCUABW+T/K22/Tpa7ajRY6vxFTnAJnk00lDOFsx9+JSq41bEIDo9zJG51PGtCqI6npGFS58kgFD2WGR2YkNCl6Rw+CMH+3GcC54EkAJEgoJfsKJjwvMoPQHFFvxALmvIgO8PLYhscL8XGkh14QC+YfmaO1hW9sno65Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1733366137; bh=nHIqGGiuAgK2EO/Tti7T55Z8JXqV4G3NKCcEKPCPqiF=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=M48+cC/+Jyz75sAF4ms2JfbXTOTAnq53N5H81rzfPaVbydYUrel7acK1gzSOysFBgJluLh5Vpou0QMAl2rKczbyj8QExq858gZK9lxUosoUx5us/RKhBh5zyiREsV6TSpFCfrGE1ch2o6oL6UGqCOH+2OpsG/gWR8CrJkZv52it5MqSgihR80EwgnLQMvDe42897NgVDkyYjVPY9fvnLPkCqM2daHPfpkjXm8UiVvJR0uNITgLk3QzvAoCN5GUg7vM0670/Uea0LH5QfpzCMyGanRxyCTXiWNT632wlXEVgEweAmBJuntUHLfFXDJg6cuCzMrRXDXTLIN7R97MAUbw== X-YMail-OSG: Nukt9uYVM1mYes30qOlsm.oGPwMnn2IVrfKK.cHaG.cVCKHxriSG.Uiw.UFYma7 DnoqckCGVRUIt3p5YGxd24hEmRNOGyXzlKp32HyqGsyWUaW5G3LWrDQrSkxyGUMyEbQdwleU6WUM 92nYFpu.EG.asbfBqlcWQa12cs6AvPdrHdpKiu3onMmVX.5CgsGpH.1FrxfHuhxwjp.RPbiX5T4n W02t8vJkmLAkIPFyKE1vyT.jvH8X96QLrcL6KdaUZMYq9yFatZp.Sgbm5tHKYp5wC1jpRyIZ01wV mubteGm4IGxFcK4mb8cEiLnTE_8xZi4AkEpDakvcswyTzqaUF3SpYJ5ilo9adPqvlA.qLSyV0fF. lrGnoqn_rrrfQ4Whth5HFtPpvzk_Ug4ldf4S5ksd3fF45o1f0is9bofUv_2IVq3vGHVNEZgCwniM YSHko7G3giFSa6JLUsd9WpAK72NsHQrS_6WtBwirL_4_VLAp2L2N9R7byD57f5PtCmhnXqH1nR31 1eGHFMFs0Fhys8llcRJk_Lh2wRi4JejXozl7VWb.h1tw.bxDcS9u8y6hwCoItuaTk8G4g8tLUhpV SM67ZysDmK7QteRCkfopDgbO3_RSF4JOUALJGwch2EZCftjxDcYUwLkJ4m1JUQRIARQJ4Si77sCQ uZu35tzsAr6kovzEsjCzcItWMWo4KPvf5H4MkyHqk77cAUv1qkocmN203XXORCZ2omdGjkydf_nx .nk0eJ6CDuYW3V2a1rhBewJzROqoXmM6uZFhw6hfZwB4t1E2UZ5M7jvih9qHlJUoUwMcHQE5.Twk guOqQ8RJoLYXMx51yMVmWKfrab_0BXNweHDwtXZ2L9tS.HvbaGuvQ95sloGxx5MRW2e.30egfBhd YjvDUxPkXJdZHr68y.tAUGhR7aE0t3mP7CKTDQzhxuAKbJZQp7x2OJlKE4WQWN6YeyuT6fBx870h w3k5RqYShQ5kSsM_1h8GFX642uG5X9OWHg7MrUWdqf9kcfhE3bIhcIWFqpl..Va.KCtYIDtjIOEb FOuhCpcxNOgKGZTEKCKeUEpBdcTod9r6CyOoIWlApnrVYLCKygGhU.r9Mh4U0HEzar_SnXotJszY AMhhsfS48t8xrZHmhWPmtZ_Bghv1SALS6yNuxLzl9j.BQqopj65ETcY1n9cSaesE.jTkqqNJWBBl X5I4ucoYdS4dHPGPYH0h5_BhkhQEsQi6uVYuzmU76sMmQFn63annr3A96E.MTa9CbTwqxtTCX4Gs K_4K_RtHMg9da1IOEZf5jdMyCl49WTo3h6vEIEPzmolpAI1UJEKoZ1DttZWBv0scfbf_FbceQb9U zEPEBsvCUK8HSEnCOCTCe4nBJ1ngnyvPPfR9lFGcpzdAhB2CFcDibZaBI9CtnmG42SNm7EhbbevB 2Pf9WkpvWFBOCIeoXcAA3X9SINW6yDrI26cH1Fzzl3GF3BAaqOCeuE3m9tJecQjGNsT12GEL2E4Q eakLyPY839KaTI_h0Xk4dZ_wi.Wa8b8sRrO9TYXMNfLtGgC9qBq4Zok33ULM.P60GXH.CcFqnkqY SAnzJ.eEYDN1.uKdDTuHV2inv6fdkdT6l99KS.FV6FMWEGy2v3sJZMyX8sEHJcXQlZqzfzzLOpEj rRGhKzagVU5tJmSmSKxafYW5zthYqGr0JcSTTZuDc6Q2Ycd_ZGS3Ni30D1OMrNBPLLFKw4kW7dSn OsVddVEN47SfPANuLcfogr0kvss2Y9949WldyL6r6y1ObFIjH8cP.rt5EIRBN52dJe4QCiEJHckr 2FJmBV9WfI0dC5oikmVUPFQsV0JBw4RPaWcnEpvjhRtFRoqEd4FnzDQ5AffdkmOXmwINQzMtz16L Wr32OIZWDNsJs9d_heiGSezzyWHNkQtbLqtxv3j5XfbU2KaLdl3UFsyT_nONhsIRTzYQKCQKcVtG YhYAJ0PfWDgeDOzP21Z94TSOlH1HbjmCreXgKLI9_oEam9pTltlzRnvPBKvg3yiWo_24dsRJj5nd Qpsher8SOB2Ns_RM3g6rBt184Ijfi.9YkNjITCEXIpg1oyIoGAP2.P5.25Iurq7OGpjhH7nxPHII z7i5dmoi9MeM.TcAPk84efAcnw3pJSla1N9kATV_nkiRwJcPEeE9IS.BNpiP9W_V97yYuYzy3XyI N98FwEFGNMG93.aeJ2yhC8K0RApzP08bTIrStWZHvMULol7LaRdNOLhNz9BEb1ANDfDTd0LUKIfU qFbrJawB_HzbGglNWATldMiCa1E46xWq3G0ns9H7Sujye6ipO4ayPGRnGE9LMIOzQP2r2ZUj4_OR jVl03X3eWKPCG6Q-- X-Sonic-MF: X-Sonic-ID: 1619e281-9b18-4a00-9271-ec591fc890a5 Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Thu, 5 Dec 2024 02:35:37 +0000 Received: by hermes--production-gq1-5dd4b47f46-5kxd4 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID f50a34fd68b3206006c974e0462a8070; Thu, 05 Dec 2024 02:35: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 16.0 \(3776.700.51.11.1\)) Subject: Re: Official armv7 PkgBase kernel-NODEBUG installation's USB2 boot gets "Fatal kernel mode data abort: 'Alignment Fault' on write" very early, at least on an OrangePi+ 2ed From: Mark Millard In-Reply-To: Date: Wed, 4 Dec 2024 18:35:24 -0800 Cc: FreeBSD ARM List , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <46C557E0-C28A-4562-B5F8-1581DA8805C9@yahoo.com> References: <74468E62-5A74-4FB4-94F6-599E5BA3A9A1@yahoo.com> <4c29d5cb-0a31-4131-a3a9-846fd4ce926f@FreeBSD.org> To: FreeBSD-STABLE Mailing List X-Mailer: Apple Mail (2.3776.700.51.11.1) 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]; 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)[]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.84:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.84:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-Rspamd-Queue-Id: 4Y3dmC4K0Sz4sV1 X-Spamd-Bar: --- On Dec 2, 2024, at 23:38, Mark Millard wrote: > Top post of identifying a new context: >=20 > Now that stable/14 is based on LLVM19, stable/14 is broken > like main [so: 15] was, at least in part. While I've not tested stable/13 for the failure, it also got an update to use LLVM 19 . So likely both of stable/1[34] need updates. > Some MFC activity looks to be required in order to boot armv7 > via stable/14 now. More may be required. Looks to me like the following (that have a mix of MFC wait times: 1 month/4 weeks vs. 1 week) spans the issues in main (and somewhat more: some VFP state corruption issues). * arm: Fix VFP state corruption during signal delivery Michal Meloun 9 = days 1 -18/+24 * arm: link all .rodata variants into one output section Michal Meloun = 2024-11-17 1 -1/+1 * arm: align data section to the supersection. Michal Meloun 2024-11-17 = 1 -3/+1 * arm: add read_frequently, read_mostly and exclusive_cache_line = sections to li... Michal Meloun 2024-11-17 1 -0/+15 * arm: fix symbols around the .ARM.exidx section Michal Meloun = 2024-11-17 1 -0/+1 * arm: Fix typo in ldscript.arm. Michal Meloun 2024-11-17 1 -1/+1 * arm: switch the BUSDMA buffers to normal uncached memory Michal Meloun = 2024-11-11 1 -1/+1 When I looked, it did not seem that any of the 1-week MFCs involved made it into a stable/1[34] yet. > The failure looks like: >=20 > . . . > mmc1: on aw_mmc1 > mmc1: No compatible cards found on bus > aw_mmc1: Spurious interrupt - no active request, rint: 0x00000004 >=20 > mmc2: on aw_mmc0 > mmcsd1: 32GB at mmc2 = 50.0MHz/4bit/32768-block > mmc2: Failed to set VCCQ for card at relative address 43690 > uhub0: 1 port with 1 removable, self powered > uhub2: 1 port with 1 removable, self powered > uhub5: 1 port with 1 removable, self powered > uhub8: 1 port with 1 removable, self powered > Root mount waiting for: usbus3 > Fatal kernel mode data abort: 'Alignment Fault' on write > trapframe: 0xc6b7dc10 > FSR=3D00000801, FAR=3Ddb0b901b, spsr=3D20000013 > r0 =3Ddb0b9000, r1 =3D00000000, r2 =3D00000006, r3 =3D00000024 > r4 =3Ddb058c80, r5 =3D00000000, r6 =3D00000001, r7 =3D00000006 > r8 =3Dc6b7dd20, r9 =3Dc0b324fc, r10=3Dc08ef8dc, r11=3Dc6b7dcb8 > r12=3D00000000, ssp=3Dc6b7dca0, slr=3Dc019f774, pc =3Dc019f524 >=20 > panic: Fatal abort > cpuid =3D 1 > time =3D 3 > KDB: stack backtrace: > Fatal kernel mode data abort: 'Translation Fault (L1)' on read > trapframe: 0xc6b7d970 > FSR=3D00000005, FAR=3Da3e89ab0, spsr=3D200001d3 > r0 =3Dc6b7da24, r1 =3D00000001, r2 =3Da3e89aad, r3 =3D63622c6d > r4 =3Dc0866e44, r5 =3Df3bea0b1, r6 =3D0000a776, r7 =3D81000000 > r8 =3Dc0813294, r9 =3Dc0b229c4, r10=3Dc6b7db1c, r11=3Dc6b7da18 > r12=3Dc6b7dad8, ssp=3Dc6b7da00, slr=3Dc0665720, pc =3Dc066974c > panic: Fatal abort > cpuid =3D 1 > time =3D 3 > KDB: stack backtrace: > Fatal kernel mode data abort: 'Translation Fault (L1)' on read > trapframe: 0xc6b7d6f0 > FSR=3D00000005, FAR=3Da3e89ab0, spsr=3D200001d3 > r0 =3Dc6b7d7a4, r1 =3D00000001, r2 =3Da3e89aad, r3 =3D63622c6d > r4 =3Dc0866e44, r5 =3Df3bea0b1, r6 =3D0000a776, r7 =3D81000000 > r8 =3Dc0813294, r9 =3Dc0b229c4, r10=3Dc6b7d89c, r11=3Dc6b7d798 > r12=3Dc6b7d858, ssp=3Dc6b7d780, slr=3Dc0665720, pc =3Dc066974c >=20 > panic: Fatal abort > cpuid =3D 1 > time =3D 3 > KDB: stack backtrace: > Fatal kernel mode data abort: 'Translation Fault (L1)' on read > trapframe: 0xc6b7d470 > FSR=3D00000005, FAR=3Da3e89ab0, spsr=3D200001d3 > r0 =3Dc6b7d524, r1 =3D00000001, r2 =3Da3e89aad, r3 =3D63622c6d > r4 =3Dc0866e44, r5 =3Df3bea0b1, r6 =3D0000a776, r7 =3D81000000 > r8 =3Dc0813294, r9 =3Dc0b229c4, r10=3Dc6b7d61c, r11=3Dc6b7d518 > r12=3Dc6b7d5d8, ssp=3Dc6b7d500, slr=3Dc0665720, pc =3Dc066974c >=20 >=20 > After that the L1 translation fault repeats over and over. >=20 >=20 >=20 > On Nov 8, 2024, at 04:49, Michal Meloun wrote: >=20 >> On 08.11.2024 4:15, Mark Millard wrote: >>> [I narrowed the artifact kernel range for the change in the type of >>> failure that happens.] >>> On Nov 7, 2024, at 17:43, Mark Millard wrote: >>>> [The change to LLVM 19 is what leads to the Alignment >>>> Fault' on write failure. Details later below.] >>>>=20 >>>> On Nov 7, 2024, at 01:42, Mark Millard wrote: >>>>=20 >>>>> Note: Unfortunately, the panics here are too early for a >>>>> dump device to be available. >>>>>=20 >>>>> Context started PkgBase upgrade from: >>>>>=20 >>>>> # uname -apKU >>>>> FreeBSD OPiP2E-RPi2v1p1 15.0-CURRENT FreeBSD 15.0-CURRENT = main-n272821-37798b1d5dd1 GENERIC-NODEBUG arm armv7 1500025 1500025 >>>>>=20 >>>>> Installed packages to be UPGRADED: >>>>> FreeBSD-dtb: 15.snap20241009161500 -> 15.snap20241028121139 = [base] >>>>> FreeBSD-kernel-generic: 15.snap20241011221604 -> = 15.snap20241106134422 [base] >>>>> FreeBSD-kernel-generic-dbg: 15.snap20241011221604 -> = 15.snap20241106134422 [base] >>>>> FreeBSD-kernel-generic-mmccam: 15.snap20241011221604 -> = 15.snap20241106134422 [base] >>>>> FreeBSD-kernel-generic-mmccam-dbg: 15.snap20241011221604 -> = 15.snap20241106134422 [base] >>>>> FreeBSD-kernel-generic-nodebug: 15.snap20241011221604 -> = 15.snap20241106134422 [base] >>>>> FreeBSD-kernel-generic-nodebug-dbg: 15.snap20241011221604 -> = 15.snap20241106134422 [base] >>>>> FreeBSD-src-sys: 15.snap20241011221604 -> = 15.snap20241106160110 [base] >>>>>=20 >>>>> (Those were installed but the FreeBSD-dtb had linux 6.4 >>>>> dtb files, not the 6.8 ones. 6.8 ones from a personal build >>>>> were copied to where they need to be. I've separately >>>>> reported the 6.4 vs. 6.8 issue.) >>>>>=20 >>>>> # ~/pkgbase-snapshot-list.sh >>>>> Via pkg-static info -C -x '^FreeBSD-' . . . >>>>> 1 FreeBSD-*-15.snap20241106160110 >>>>> 6 FreeBSD-*-15.snap20241106134422 >>>>> 1 FreeBSD-*-15.snap20241028121139 >>>>> 3 FreeBSD-*-15.snap20241011221604 >>>>> 2 FreeBSD-*-15.snap20241011210446 >>>>> 38 FreeBSD-*-15.snap20241011182434 >>>>> 4 FreeBSD-*-15.snap20241011073851 >>>>> 5 FreeBSD-*-15.snap20241010141501 >>>>> 1 FreeBSD-*-15.snap20241010120743 >>>>> 296 FreeBSD-*-15.snap20241009161500 >>>>> Instead via /var/cache/pkg/*.snap*.pkg . . . >>>>> 1 FreeBSD-*-15.snap20241106160110 >>>>> 6 FreeBSD-*-15.snap20241106134422 >>>>> 1 FreeBSD-*-15.snap20241028121139 >>>>> 10 FreeBSD-*-15.snap20241011221604 >>>>> 2 FreeBSD-*-15.snap20241011210446 >>>>> 38 FreeBSD-*-15.snap20241011182434 >>>>> 4 FreeBSD-*-15.snap20241011073851 >>>>> 5 FreeBSD-*-15.snap20241010141501 >>>>> 1 FreeBSD-*-15.snap20241010120743 >>>>> 297 FreeBSD-*-15.snap20241009161500 >>>>>=20 >>>>>=20 >>>>> The failure (kernel-GENERIC-NODEBUG): >>>>>=20 >>>>> . . . >>>>> Root mount waiting for: usbus3 CAM >>>>> Fatal kernel mode data abort: 'Alignment Fault' on write >>>>> trapframe: 0xc6c9ac10 >>>>> FSR=3D00000801, FAR=3Ddb23209b, spsr=3D20000013 >>>>> r0 =3Ddb232080, r1 =3D00000000, r2 =3D00000006, r3 =3D00000024 >>>>> r4 =3Ddb19e280, r5 =3D00000000, r6 =3D00000001, r7 =3D00000006 >>>>> r8 =3Dc6c9ad20, r9 =3Dc0b7973c, r10=3Dc092074c, r11=3Dc6c9acb8 >>>>> r12=3D00000000, ssp=3Dc6c9aca0, slr=3Dc01b01d8, pc =3Dc01aff88 >>>>>=20 >>>>> panic: Fatal abort >>>>> cpuid =3D 1 >>>>> time =3D 3 >>>>> KDB: stack backtrace: >>>>> db_trace_self() at db_trace_self >>>>> pc =3D 0xc0667004 lr =3D 0xc0078630 = (db_trace_self_wrapper+0x30) >>>>> sp =3D 0xc6c9a9c8 fp =3D 0xc6c9aae0 >>>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x30 >>>>> pc =3D 0xc0078630 lr =3D 0xc0328db8 (vpanic+0x140) >>>>> sp =3D 0xc6c9aae8 fp =3D 0xc6c9ab08 >>>>> r4 =3D 0x00000100 r5 =3D 0x00000000 >>>>> r6 =3D 0xc084d1f1 r7 =3D 0xc0b69a94 >>>>> vpanic() at vpanic+0x140 >>>>> pc =3D 0xc0328db8 lr =3D 0xc0328c78 (vpanic) >>>>> sp =3D 0xc6c9ab10 fp =3D 0xc6c9ab14 >>>>> r4 =3D 0xc6c9ac10 r5 =3D 0x00000013 >>>>> r6 =3D 0xdb23209b r7 =3D 0x00000001 >>>>> r8 =3D 0x00000801 r9 =3D 0x00000013 >>>>> r10 =3D 0xdb23209b >>>>> vpanic() at vpanic >>>>> pc =3D 0xc0328c78 lr =3D 0xc068c8e8 (abort_align) >>>>> sp =3D 0xc6c9ab1c fp =3D 0xc6c9ab48 >>>>> r4 =3D 0x00000001 r5 =3D 0x00000801 >>>>> r6 =3D 0x00000013 r7 =3D 0xdb23209b >>>>> r8 =3D 0xc6c9ab14 r9 =3D 0xc0328c78 >>>>> r10 =3D 0xc6c9ab1c >>>>> abort_align() at abort_align >>>>> pc =3D 0xc068c8e8 lr =3D 0xc068c958 (abort_align+0x70) >>>>> sp =3D 0xc6c9ab50 fp =3D 0xc6c9ab68 >>>>> r4 =3D 0xc6d21c00 r10 =3D 0xdb23209b >>>>> abort_align() at abort_align+0x70 >>>>> pc =3D 0xc068c958 lr =3D 0xc068c5e0 (abort_handler+0x430) >>>>> sp =3D 0xc6c9ab70 fp =3D 0xc6c9ac08 >>>>> r4 =3D 0x00000000 r10 =3D 0xdb23209b >>>>> abort_handler() at abort_handler+0x430 >>>>> pc =3D 0xc068c5e0 lr =3D 0xc0669868 (exception_exit) >>>>> sp =3D 0xc6c9ac10 fp =3D 0xc6c9acb8 >>>>> r4 =3D 0xdb19e280 r5 =3D 0x00000000 >>>>> r6 =3D 0x00000001 r7 =3D 0x00000006 >>>>> r8 =3D 0xc6c9ad20 r9 =3D 0xc0b7973c >>>>> r10 =3D 0xc092074c >>>>> exception_exit() at exception_exit >>>>> pc =3D 0xc0669868 lr =3D 0xc01b01d8 = (usb_msc_auto_quirk+0xfc) >>>>> sp =3D 0xc6c9aca0 fp =3D 0xc6c9acb8 >>>>> r0 =3D 0xdb232080 r1 =3D 0x00000000 >>>>> r2 =3D 0x00000006 r3 =3D 0x00000024 >>>>> r4 =3D 0xdb19e280 r5 =3D 0x00000000 >>>>> r6 =3D 0x00000001 r7 =3D 0x00000006 >>>>> r8 =3D 0xc6c9ad20 r9 =3D 0xc0b7973c >>>>> r10 =3D 0xc092074c r12 =3D 0x00000000 >>>>> bbb_command_start() at bbb_command_start+0x4c >>>>> pc =3D 0xc01aff88 lr =3D 0xc01b01d8 = (usb_msc_auto_quirk+0xfc) >>>>> sp =3D 0xc6c9acc0 fp =3D 0xc6c9acf8 >>>>> r4 =3D 0xdb16d800 r5 =3D 0xdb19e280 >>>>> r6 =3D 0x00000001 r10 =3D 0xc092074c >>>>> usb_msc_auto_quirk() at usb_msc_auto_quirk+0xfc >>>>> pc =3D 0xc01b01d8 lr =3D 0xc01a4bd8 = (usb_alloc_device+0x9c4) >>>>> sp =3D 0xc6c9ad00 fp =3D 0xc6c9ad68 >>>>> r4 =3D 0x00000000 r5 =3D 0x00000001 >>>>> r6 =3D 0x00000000 r7 =3D 0x00000002 >>>>> r8 =3D 0xdb16d800 r9 =3D 0xda241c78 >>>>> r10 =3D 0x000003ee >>>>> usb_alloc_device() at usb_alloc_device+0x9c4 >>>>> pc =3D 0xc01a4bd8 lr =3D 0xc01ad16c (uhub_explore+0x494) >>>>> sp =3D 0xc6c9ad70 fp =3D 0xc6c9adc0 >>>>> r4 =3D 0x00000000 r5 =3D 0x00000000 >>>>> r6 =3D 0xdb16e800 r7 =3D 0x00000000 >>>>> r8 =3D 0xdb18c200 r9 =3D 0x00000001 >>>>> r10 =3D 0x00000000 >>>>> uhub_explore() at uhub_explore+0x494 >>>>> pc =3D 0xc01ad16c lr =3D 0xc0198654 (usb_bus_explore+0x1d4) >>>>> sp =3D 0xc6c9adc8 fp =3D 0xc6c9add8 >>>>> r4 =3D 0xda241c78 r5 =3D 0xdb16e800 >>>>> r6 =3D 0x00000000 r7 =3D 0xda241d6c >>>>> r8 =3D 0xc09b0b5f r9 =3D 0x00000001 >>>>> r10 =3D 0xda241d1c >>>>> usb_bus_explore() at usb_bus_explore+0x1d4 >>>>> pc =3D 0xc0198654 lr =3D 0xc01b22d0 (usb_process+0x124) >>>>> sp =3D 0xc6c9ade0 fp =3D 0xc6c9ae10 >>>>> r4 =3D 0xda241d0c r5 =3D 0xda241d14 >>>>> usb_process() at usb_process+0x124 >>>>> pc =3D 0xc01b22d0 lr =3D 0xc02da4f0 (fork_exit+0xb0) >>>>> sp =3D 0xc6c9ae18 fp =3D 0xc6c9ae38 >>>>> r4 =3D 0xc6c9ae40 r5 =3D 0xc6d21c00 >>>>> r6 =3D 0xc6d08740 r7 =3D 0xda241d0c >>>>> r8 =3D 0xc01b21ac r9 =3D 0x00000000 >>>>> r10 =3D 0x00000000 >>>>> fork_exit() at fork_exit+0xb0 >>>>> pc =3D 0xc02da4f0 lr =3D 0xc06697fc (swi_exit) >>>>> sp =3D 0xc6c9ae40 fp =3D 0x00000000 >>>>> r4 =3D 0xc01b21ac r5 =3D 0xda241d0c >>>>> r6 =3D 0x00000000 r7 =3D 0x00000000 >>>>> r8 =3D 0x00000000 r10 =3D 0x00000000 >>>>> swi_exit() at swi_exit >>>>> pc =3D 0xc06697fc lr =3D 0xc06697fc (swi_exit) >>>>> sp =3D 0xc6c9ae40 fp =3D 0x00000000 >>>>> KDB: enter: panic >>>>> [ thread pid 14 tid 100069 ] >>>>> Stopped at kdb_enter+0x54: ldrb r15, [r15, r15, ror r15]! >>>>> db> >>>>=20 >>>> Using just available official artifact kernels for testing >>>> I've established that 0953460ce149 (and various from before >>>> that) does not have the problem: >>>>=20 >>>> Wed, 23 Oct 2024 >>>> =E2=80=A2 git: 5c92f84bb607 - main - LinuxKPI: update = rcu_dereference_*() and lockdep_is_held() Bjoern A. Zeeb >>>> =E2=80=A2 git: 6fa91acca40d - main - conf/NOTES: Remove trailing = whitespace Li-Wen Hsu >>>> =E2=80=A2 git: 91b7b225b2ce - main - LINT: Add mac_do Li-Wen Hsu >>>> =E2=80=A2 git: 419249c1cacc - main - Revert "LINT: Add mac_do" = Li-Wen Hsu >>>> =E2=80=A2 Re: git: 419249c1cacc - main - Revert "LINT: Add = mac_do" Baptiste Daroussin >>>> =E2=80=A2 Re: git: 13da1af1cd67 - main - libcxxrt: Update to = upstream 698997bfde1f John Baldwin >>>> =E2=80=A2 Re: git: 419249c1cacc - main - Revert "LINT: Add = mac_do" John Baldwin >>>> =E2=80=A2 git: 0953460ce149 - main - libc: fix access mode tests = in fmemopen(3) Ed Maste >>>>=20 >>>> So the above one worked. >>>>=20 >>>> The next available kernel to test was f3dbef108212 (the bump for = LLVM19 >>>> at the end of the below): >>>>=20 >>>> =E2=80=A2 RE: git: 6a07e67fb7a8 - main - vm_meter: Fix laundry = accounting Mark Millard >>>> =E2=80=A2 git: 6b9f7133aba4 - main - libc: Add one more check in = new fmemopen test Ed Maste >>>> =E2=80=A2 git: 0fca6ea1d4ee - main - Merge llvm-project main = llvmorg-19-init-18630-gf2ccf80136a0 Dimitry Andric >>>> =E2=80=A2 git: 36b606ae6aa4 - main - Merge llvm-project = release/19.x llvmorg-19.1.0-rc1-0-ga4902a36d5c2 Dimitry Andric >>>> =E2=80=A2 git: 3f157662c0ef - main - Tentatively apply = https://github.com/llvm/llvm-project/pull/101403 Dimitry Andric >>>> =E2=80=A2 git: d575077527d4 - main - bsd.sys.mk: for clang >=3D = 19, similar to gcc >=3D 8.1, turn off -Werror for = -Wcast-function-type-mismatch. Dimitry Andric >>>> =E2=80=A2 git: 36d486cc2ecd - main - Fix enum warning in = ath_hal's ar9002 Dimitry Andric >>>> =E2=80=A2 git: 6846ab2fb663 - main - libcxx simd_utils.h: only = enable _LIBCPP_HAS_ALGORITHM_VECTOR_UTILS for clang >=3D 15, since older = versions do not support the required builtins. Dimitry Andric >>>> =E2=80=A2 git: 81e300df5e65 - main - libcxx atomic_ref.h: add = typename keyword for difference_type declarations, otherwise older clang = versions cannot compile this header. Dimitry Andric >>>> =E2=80=A2 git: 6b4981df6008 - main - libcxx cstdlib, cwchar: = avoid using long long functions if not supported, even for older = compilers that do not support the using_if_exists attribute. Dimitry = Andric >>>> =E2=80=A2 git: 2f6d6eaf2d51 - main - libcxx-compat: revert = llvmorg-19-init-18063-g561246e90282: Dimitry Andric >>>> =E2=80=A2 git: 04f5b79cfa49 - main - libcxx-compat: revert = llvmorg-19-init-18062-g4dfa75c663e5: Dimitry Andric >>>> =E2=80=A2 git: e8054e44f4ca - main - libcxx-compat: revert = llvmorg-19-init-17853-g578c6191eff7: Dimitry Andric >>>> =E2=80=A2 git: 0bec0529b1d7 - main - libcxx-compat: revert = llvmorg-19-init-17728-g30cc12cd818d: Dimitry Andric >>>> =E2=80=A2 git: e8847079df1b - main - libcxx-compat: revert = llvmorg-19-init-17727-g0eebb48fcfbc: Dimitry Andric >>>> =E2=80=A2 git: 2f2ebe758bea - main - libcxx-compat: revert = llvmorg-19-init-17473-g69fecaa1a455: Dimitry Andric >>>> =E2=80=A2 git: 1199d38d8ec7 - main - libcxx-compat: revert = llvmorg-19-init-8667-g472b612ccbed: Dimitry Andric >>>> =E2=80=A2 git: a7b2d7f261b8 - main - libcxx-compat: revert = llvmorg-19-init-5639-ga10aa4485e83: Dimitry Andric >>>> =E2=80=A2 git: f3859a1a13a1 - main - libcxx-compat: revert = llvmorg-19-init-4504-g937a5396cf3e: Dimitry Andric >>>> =E2=80=A2 git: 072b5fb698ab - main - libcxx-compat: revert = llvmorg-19-init-4003-g55357160d0e1: Dimitry Andric >>>> =E2=80=A2 git: b60301d8b594 - main - libcxx-compat: don't remove = headers that were reintroduced by reverts Dimitry Andric >>>> =E2=80=A2 git: 2e861daab905 - main - libcxx-compat: install = headers that were reintroduced by reverts Dimitry Andric >>>> =E2=80=A2 git: ff6c8447844b - main - libcxx-compat: update = libcxx.imp for headers that were reintroduced by reverts Dimitry Andric >>>> =E2=80=A2 git: 52418fc2be8e - main - Merge llvm-project = release/19.x llvmorg-19.1.0-rc2-0-gd033ae172d1c Dimitry Andric >>>> =E2=80=A2 git: 62987288060f - main - Merge llvm-project = release/19.x llvmorg-19.1.0-rc3-0-g437434df21d8 Dimitry Andric >>>> =E2=80=A2 git: 6c4b055cfb6b - main - Merge llvm-project = release/19.x llvmorg-19.1.0-rc4-0-g0c641568515a Dimitry Andric >>>> =E2=80=A2 git: 835c3a3e69af - main - Merge commit 6dbdb8430b49 = from llvm git (by Nikolas Klauser): Dimitry Andric >>>> =E2=80=A2 git: c80e69b00d97 - main - Merge llvm-project = release/19.x llvmorg-19.1.0-0-ga4bf6cd7cfb1 Dimitry Andric >>>> =E2=80=A2 git: 6e516c87b6d7 - main - Merge llvm-project = release/19.x llvmorg-19.1.1-0-gd401987fe349 Dimitry Andric >>>> =E2=80=A2 git: 5deeebd8c6ca - main - Merge llvm-project = release/19.x llvmorg-19.1.2-0-g7ba7d8e2f7b6 Dimitry Andric >>>> =E2=80=A2 git: f3dbef108212 - main - Bump __FreeBSD_version for = llvm 19.1.2 merge Dimitry Andric >>>>=20 >>>> f3dbef108212 gets the: >>>>=20 >>>> "Fatal kernel mode data abort: 'Alignment Fault' on write" >>>>=20 >>>> boot failure for artifact kernel. 6b9f7133aba4 does nit >>>> seem a likely source of the problem, basically leaving the >>>> LLVM changes as what is at issue. >>>>=20 >>>> I'll note that artifact kernels are witness kernels. So >>>> this exploration adds to the distinctions observed >>>> compared to the prior notes. >>>>=20 >>>>> Looking at bbb_command_start() 's pc: >>>>>=20 >>>>> # llvm-addr2line -e /boot/kernel.GENERIC-NODEBUG/kernel 0xc01aff88 >>>>> /home/pkgbuild/worktrees/main/sys/dev/usb/usb_msctest.c:554 >>>>>=20 >>>>> What leads to that line is: >>>>>=20 >>>>> = /*------------------------------------------------------------------------= * >>>>> * bbb_command_start - execute a SCSI command synchronously >>>>> * >>>>> * Return values >>>>> * 0: Success >>>>> * Else: Failure >>>>> = *------------------------------------------------------------------------*= / >>>>> static int >>>>> bbb_command_start(struct bbb_transfer *sc, uint8_t dir, uint8_t = lun, >>>>> void *data_ptr, size_t data_len, void *cmd_ptr, size_t cmd_len, >>>>> usb_timeout_t data_timeout) >>>>> { >>>>> sc->lun =3D lun; >>>>> sc->dir =3D data_len ? dir : DIR_NONE; >>>>> sc->data_ptr =3D data_ptr; >>>>> sc->data_len =3D data_len; >>>>> sc->data_rem =3D data_len; >>>>> sc->data_timeout =3D (data_timeout + USB_MS_HZ); >>>>> sc->actlen =3D 0; >>>>> sc->error =3D 0; >>>>> sc->cmd_len =3D cmd_len; >>>>> memset(&sc->cbw->CBWCDB, 0, sizeof(sc->cbw->CBWCDB)); >>>>>=20 >>>>> The memset line is line 554 of sys/dev/usb/usb_msctest.c . >>>>=20 >>>> The below looks to be a separate problem based on >>>> some later FreeBSD kernel update than the above. >>>>=20 >>>>> I'll note that attempting to use the WITNESS variant of the kernel >>>>> ( /boot/kernel/ ) gets a different, even earlier failure: >>>>>=20 >>>>> . . . >>>>> VT: init without driver. >>>>> panic: acquiring blockable sleep lock with spinlock or critical = section held (sleep mutex) pmap @ = /home/pkgbuild/worktrees/main/sys/arm/arm/pmap-v6.c:6455 >>>>=20 >>>> I do know that d021d3b3c675 at the end of the below >>>> shows this failure --before the system has a chance >>>> to get the usb related write alignment failure >>>> reported above. >>>>=20 >>>> I have not explored where in the below range the >>>> behavior changes (for what is available as an >>>> official artifact kernel). It seems unlikely that >>>> any of the below would actually boot: it is likely >>>> a question of which of the 2 (or more) failure >>>> types happen for each instead. >>> The last before "Thu, 24, Oct 2024" was: >>> =E2=80=A2 git: 8b2e7da70855 - main - llvm19: permit = incremental builds from llvm18 Brooks Davis >>> That is the last available artifact kernel that gets the >>> original usb related write alignment type of failure. >>>> Thu, 24 Oct 2024 >>>> =E2=80=A2 git: 34951b0b9e78 - main - swap_pager: move = scan_all_shadowed, use iterators Doug Moore >>>> =E2=80=A2 git: 2ac21f2c98ed - main - x86 specialreg.h: visually = align %cr4 and MSR_EFER bit mask definitions Konstantin Belousov >>>> =E2=80=A2 git: cc11bc1150d5 - main - x86 specialreg.h: add all = defined bits for %cr4 Konstantin Belousov >>>> =E2=80=A2 git: cc4b25f10211 - main - x86 specialreg: reorder %cr3 = bits masks definitions by value Konstantin Belousov >>>> =E2=80=A2 git: 5999b74e9637 - main - x86 specialreg: add bit = masks definitions for LAM in %cr3 Konstantin Belousov >>>> =E2=80=A2 git: 6308db659f2a - main - x86 specialreg: add bit = masks definitions for EFER features Konstantin Belousov >>>> =E2=80=A2 git: 9f718b57b846 - main - x86 specialreg: add bit = masks definitions for LASS and LAM features Konstantin Belousov >>>> =E2=80=A2 git: 3360a15898ce - main - net: route: convert routing = statistics to a sysctl Kyle Evans >>>> =E2=80=A2 Re: git: 3360a15898ce - main - net: route: convert = routing statistics to a sysctl Kyle Evans >>>> =E2=80=A2 git: 77b70ad751df - main - e1000: Move I219 LM19/V19 to = ADL Kevin Bowling >>> The last above is the first available artifact kernel that >>> that gets the different error. There are no armv7 artifact >>> kernels between 8b2e7da70855 and 77b70ad751df . >>> So something from 34951b0b9e78 .. 77b70ad751df leads to >>> the change in the type of failure. I've no clue what. >>> It looked to me like the x86 commits and e1000 commit had >>> no chance of contributing to the armv7 context. Thus >>> who I added to the CC vs. did not add. >>>> =E2=80=A2 git: d64442a89896 - main - arm{,64}: use genassym for = INTR_ROOT_* values Kyle Evans >>>> =E2=80=A2 git: 536c8d948e85 - main - intrng: change = multi-interrupt root support type to enum Kyle Evans >>>> =E2=80=A2 git: 4f12b529f404 - main - sys/intr.h: formally depend = on machine/intr.h Kyle Evans >>>> =E2=80=A2 git: a5b1eecbed07 - main - Apply workaround for = building llvm-project with WITHOUT_LLVM_ASSERTIONS Dimitry Andric >>>> =E2=80=A2 git: 1c83996beda7 - main - Adjust = LLVM_ENABLE_ABI_BREAKING_CHECKS depending on NDEBUG Dimitry Andric >>>> =E2=80=A2 git: b2dd4970c7b5 - main - dev/gpio: Mask all pl011 = interrupts Andrew Turner >>>> =E2=80=A2 git: 3b03e1bb8615 - main - intrng: Store the IPI = priority Andrew Turner >>>> =E2=80=A2 git: 6204391e99ca - main - arm64: Check TDP_NOFAULTING = in a data abort Andrew Turner >>>> =E2=80=A2 git: a84653c5db25 - main - arm64: Don't enable = interrupts when in a spinlock Andrew Turner >>>> =E2=80=A2 git: d7f930b80e89 - main - arm64: Implement = efi_rt_arch_call Andrew Turner >>>> =E2=80=A2 git: 8efb1500d4f1 - main - arm64: Enable handling EFI = runtime service faults Andrew Turner >>>> =E2=80=A2 git: 9693241188aa - main - sound: Call DSP_REGISTERED = before PCM_DETACHING Christos Margiolis >>>> =E2=80=A2 git: bb5e3ac1a7b7 - main - sound: Use DSP_REGISTERED in = dsp_clone() Christos Margiolis >>>> =E2=80=A2 git: a4111e9dc722 - main - sound: Change PCMDIR_* = numbering Christos Margiolis >>>> =E2=80=A2 git: 802c78f5194e - main - sound: Untangle dsp_cdevs[] = and dsp_unit2name() confusion Christos Margiolis >>>> =E2=80=A2 git: b1bb6934bb87 - main - sound: Fix build error in = chm_mkname() KASSERT Christos Margiolis >>>> =E2=80=A2 git: ce20b48a60fb - main - sctp: improve debug output = Michael Tuexen >>>> =E2=80=A2 git: e4ac0183a1a8 - main - sctp: cleanup Michael Tuexen >>>> =E2=80=A2 git: 8c8ebbb04518 - main - bhyve ahci: Improve = robustness of TRIM handling John Baldwin >>>> =E2=80=A2 git: f0bc751d6fb4 - main - csa: Use pci_find_device to = simplify clkrun_hack John Baldwin >>>> =E2=80=A2 git: d96ba5a62365 - main - config: Remove a stray = semicolon Zhenlei Huang >>>> =E2=80=A2 git: 56b17de1e836 - main - makefs: Remove a stray = semicolon Zhenlei Huang >>>> =E2=80=A2 git: 88b71d1fe054 - main - arm64: rockchip: Remove a = stray semicolon Zhenlei Huang >>>> =E2=80=A2 git: b4856b8e9d87 - main - LinuxKPI: Remove stray = semicolons Zhenlei Huang >>>> =E2=80=A2 git: 75ff90814aec - main - enic: Remove a stray = semicolon Zhenlei Huang >>>> =E2=80=A2 git: 6ccf4f4071c5 - main - mana: Remove stray = semicolons Zhenlei Huang >>>> =E2=80=A2 git: 86a2c910c05c - main - mpi3mr: Remove a stray = semicolon Zhenlei Huang >>>> =E2=80=A2 git: 36756195a342 - main - ocs_fc: Remove a stray = semicolon Zhenlei Huang >>>> =E2=80=A2 git: 2f395cfda8b5 - main - tcp cc: Remove a stray = semicolon Zhenlei Huang >>>> =E2=80=A2 git: f3a097d0312c - main - netstat: switch to using the = sysctl-exported stats for live stats Kyle Evans >>>> =E2=80=A2 git: 656991b0c629 - main - locks: augment lock_class = with lc_trylock method Gleb Smirnoff >>>> =E2=80=A2 git: efcb2ec8cb81 - main - callout: provide = CALLOUT_TRYLOCK flag Gleb Smirnoff >>>> =E2=80=A2 git: bffebc336f4e - main - tcp: use CALLOUT_TRYLOCK for = the TCP callout Gleb Smirnoff >>>> =E2=80=A2 git: d021d3b3c675 - main - tcp: get rid of = TDP_INTCPCALLOUT Gleb Smirnoff >>>>> cpuid =3D 0 >>>>> time =3D 1 >>>>> KDB: stack backtrace: >>>>> Fatal kernel mode data abort: 'Translation Fault (L1)' on read >>>>> trapframe: 0xc0f14568 >>>>> FSR=3D00000005, FAR=3Ddb7fcfb1, spsr=3D200001d3 >>>>> r0 =3Dc0f1465c, r1 =3D00000001, r2 =3Ddb7fcfae, r3 =3D1b000a4e >>>>> r4 =3Dc07fc55c, r5 =3D8fce1b89, r6 =3D00006f3e, r7 =3D81000000 >>>>> r8 =3Dc07c4b6c, r9 =3Dc094ace8, r10=3Dc09741d8, r11=3Dc0f14618 >>>>> r12=3Dc0f146c4, ssp=3Dc0f145fc, slr=3Dc0601428, pc =3Dc062686c >>>>>=20 >>>>> panic: Fatal abort >>>>> cpuid =3D 0 >>>>> time =3D 1 >>>>> KDB: stack backtrace: >>>>> Fatal kernel mode data abort: 'Translation Fault (L1)' on read >>>>> trapframe: 0xc0f141f0 >>>>> FSR=3D00000005, FAR=3Ddb7fcfb1, spsr=3D200001d3 >>>>> r0 =3Dc0f142e4, r1 =3D00000001, r2 =3Ddb7fcfae, r3 =3D1b000a4e >>>>> r4 =3Dc07fc55c, r5 =3D8fce1b89, r6 =3D00006f3e, r7 =3D81000000 >>>>> r8 =3Dc07c4b6c, r9 =3Dc094ace8, r10=3Dc09741d8, r11=3Dc0f142a0 >>>>> r12=3Dc0f1434c, ssp=3Dc0f14284, slr=3Dc0601428, pc =3Dc062686c >>>>>=20 >>>>> panic: Fatal abort >>>>> cpuid =3D 0 >>>>> time =3D 1 >>>>> KDB: stack backtrace: >>>>> Fatal kernel mode data abort: 'Translation Fault (L1)' on read >>>>> trapframe: 0xc0f13e78 >>>>> FSR=3D00000005, FAR=3Ddb7fcfb1, spsr=3D200001d3 >>>>> r0 =3Dc0f13f6c, r1 =3D00000001, r2 =3Ddb7fcfae, r3 =3D1b000a4e >>>>> r4 =3Dc07fc55c, r5 =3D8fce1b89, r6 =3D00006f3e, r7 =3D81000000 >>>>> r8 =3Dc07c4b6c, r9 =3Dc094ace8, r10=3Dc09741d8, r11=3Dc0f13f28 >>>>> r12=3Dc0f13fd4, ssp=3Dc0f13f0c, slr=3Dc0601428, pc =3Dc062686c >>>>>=20 >>>>> panic: Fatal abort >>>>> cpuid =3D 0 >>>>> time =3D 1 >>>>> KDB: stack backtrace: >>>>> Fatal kernel mode data abort: 'Translation Fault (L1)' on read >>>>> trapframe: 0xc0f13b00 >>>>> FSR=3D00000005, FAR=3Ddb7fcfb1, spsr=3D200001d3 >>>>> r0 =3Dc0f13bf4, r1 =3D00000001, r2 =3Ddb7fcfae, r3 =3D1b000a4e >>>>> r4 =3Dc07fc55c, r5 =3D8fce1b89, r6 =3D00006f3e, r7 =3D81000000 >>>>> r8 =3Dc07c4b6c, r9 =3Dc094ace8, r10=3Dc09741d8, r11=3Dc0f13bb0 >>>>> r12=3Dc0f13c5c, ssp=3Dc0f13b94, slr=3Dc0601428, pc =3Dc062686c >>>>>=20 >>>>> panic: Fatal abort >>>>> cpuid =3D 0 >>>>> time =3D 1 >>>>> KDB: stack backtrace: >>>>> Fatal kernel mode data abort: 'Translation Fault (L1)' on read >>>>> trapframe: 0xc0f13788 >>>>> FSR=3D00000005, FAR=3Ddb7fcfb1, spsr=3D200001d3 >>>>> r0 =3Dc0f1387c, r1 =3D00000001, r2 =3Ddb7fcfae, r3 =3D1b000a4e >>>>> r4 =3Dc07fc55c, r5 =3D8fce1b89, r6 =3D00006f3e, r7 =3D81000000 >>>>> r8 =3Dc07c4b6c, r9 =3Dc094ace8, r10=3Dc09741d8, r11=3Dc0f13838 >>>>> r12=3Dc0f138e4, ssp=3Dc0f1381c, slr=3Dc0601428, pc =3Dc062686c >>>>>=20 >>>>> . . . >>>>>=20 >>>>> Looking: >>>>>=20 >>>>> # llvm-addr2line -e /boot/kernel.GENERIC-NODEBUG/kernel 0xc062686c >>>>> /home/pkgbuild/worktrees/main/sys/vm/uma_core.c:5676 >>>>>=20 >>>>> static int >>>>> sysctl_handle_uma_zone_frees(SYSCTL_HANDLER_ARGS) >>>>> { >>>>> uma_zone_t zone =3D arg1; >>>>> uint64_t cur; >>>>>=20 >>>>> cur =3D uma_zone_get_frees(zone); >>>>> return (sysctl_handle_64(oidp, &cur, 0, req)); >>>>> } >>>>>=20 >>>>> The "return" line is 5676 of sys/vm/uma_core.c . >>>>>=20 >>>>>=20 >>>>> Also, for what leads up to: >>>>>=20 >>>>> /home/pkgbuild/worktrees/main/sys/arm/arm/pmap-v6.c:6455 >>>>>=20 >>>>> /* >>>>> * The implementation of pmap_fault() uses IN_RANGE2() macro which >>>>> * depends on the fact that given range size is a power of 2. >>>>> */ >>>>> CTASSERT(powerof2(NB_IN_PT1)); >>>>> CTASSERT(powerof2(PT2MAP_SIZE)); >>>>>=20 >>>>> #define IN_RANGE2(addr, start, size) \ >>>>> ((vm_offset_t)(start) =3D=3D ((vm_offset_t)(addr) & ~((size) - = 1))) >>>>>=20 >>>>> /* >>>>> * Handle access and R/W emulation faults. >>>>> */ >>>>> int >>>>> pmap_fault(pmap_t pmap, vm_offset_t far, uint32_t fsr, int idx, = bool usermode) >>>>> { >>>>> pt1_entry_t *pte1p, pte1; >>>>> pt2_entry_t *pte2p, pte2; >>>>>=20 >>>>> if (pmap =3D=3D NULL) >>>>> pmap =3D kernel_pmap; >>>>>=20 >>>>> /* >>>>> * In kernel, we should never get abort with FAR which is in = range of >>>>> * pmap->pm_pt1 or PT2MAP address spaces. If it happens, stop = here >>>>> * and print out a useful abort message and even get to the = debugger >>>>> * otherwise it likely ends with never ending loop of aborts. >>>>> */ >>>>> if (__predict_false(IN_RANGE2(far, pmap->pm_pt1, NB_IN_PT1))) = { >>>>> /* >>>>> * All L1 tables should always be mapped and present. >>>>> * However, we check only current one herein. For = user mode, >>>>> * only permission abort from malicious user is not = fatal. >>>>> * And alignment abort as it may have higher = priority. >>>>> */ >>>>> if (!usermode || (idx !=3D FAULT_ALIGN && idx !=3D = FAULT_PERM_L2)) { >>>>> CTR4(KTR_PMAP, "%s: pmap %#x pm_pt1 %#x far = %#x", >>>>> __func__, pmap, pmap->pm_pt1, far); >>>>> panic("%s: pm_pt1 abort", __func__); >>>>> } >>>>> return (KERN_INVALID_ADDRESS); >>>>> } >>>>> if (__predict_false(IN_RANGE2(far, PT2MAP, PT2MAP_SIZE))) { >>>>> /* >>>>> * PT2MAP should be always mapped and present in = current >>>>> * L1 table. However, only existing L2 tables are = mapped >>>>> * in PT2MAP. For user mode, only L2 translation = abort and >>>>> * permission abort from malicious user is not fatal. >>>>> * And alignment abort as it may have higher = priority. >>>>> */ >>>>> if (!usermode || (idx !=3D FAULT_ALIGN && >>>>> idx !=3D FAULT_TRAN_L2 && idx !=3D = FAULT_PERM_L2)) { >>>>> CTR4(KTR_PMAP, "%s: pmap %#x PT2MAP %#x far = %#x", >>>>> __func__, pmap, PT2MAP, far); >>>>> panic("%s: PT2MAP abort", __func__); >>>>> } >>>>> return (KERN_INVALID_ADDRESS); >>>>> } >>>>>=20 >>>>> /* >>>>> * A pmap lock is used below for handling of access and R/W = emulation >>>>> * aborts. They were handled by atomic operations before so = some >>>>> * analysis of new situation is needed to answer the = following question: >>>>> * Is it safe to use the lock even for these aborts? >>>>> * >>>>> * There may happen two cases in general: >>>>> * >>>>> * (1) Aborts while the pmap lock is locked already - this = should not >>>>> * happen as pmap lock is not recursive. However, under pmap = lock only >>>>> * internal kernel data should be accessed and such data = should be >>>>> * mapped with A bit set and NM bit cleared. If double abort = happens, >>>>> * then a mapping of data which has caused it must be fixed. = Further, >>>>> * all new mappings are always made with A bit set and the = bit can be >>>>> * cleared only on managed mappings. >>>>> * >>>>> * (2) Aborts while another lock(s) is/are locked - this = already can >>>>> * happen. However, there is no difference here if it's = either access or >>>>> * R/W emulation abort, or if it's some other abort. >>>>> */ >>>>>=20 >>>>> PMAP_LOCK(pmap); >>>>>=20 >>>>> That "PMAP_LOCK(pmap);" line is line 6455 of sys/arm/arm/pmap-v6.c = . >>>>>=20 >>>>>=20 >>>>> FYI: Running the prior kernel.GENERIC-NODEBUG/ ( called >>>>> kernel.GENERIC-NODEBUG.good/ ) continues to operate >>>>> normally. I do not have the older PkgBase kernel/ around >>>>> to try, unfortunately. >>> I'll remind that this is from using official FreeBSD builds >>> of the kernel versions that I tested, not from my personal >>> build context. >>> =3D=3D=3D >>> Mark Millard >>> marklmi at yahoo.com >> Hi Mark, >>=20 >> Please see https://reviews.freebsd.org/D47485 >>=20 >> Unfortunately, I see 2 problems with llvm 19. >>=20 >> The first is regression, the compiler generates inline memset() = accessing non-aligned data with sub-optimal instructions (with word = access). This regression triggers bug in the kernel (which should be = fixed in D47485). >>=20 >> Second, regarding "panic: acquiring blockable sleep lock" is due to = an bug in lld. It mis-links the ".ARM.exidx" section on the output = binary, which is used by the stack unwinder in the kernel. >> I don't have a fix for this for now, so you have to use the linker = from llvm18 as a workaround. >>=20 >> I'm not sure if I have enough free cycles to manage both issues on = the llvm side... >=20 >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Dec 7 09:56:11 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Y53SN12XJz5gqcp for ; Sat, 07 Dec 2024 09:56:52 +0000 (UTC) (envelope-from furaisanjin@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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Y53SL4hJvz4PZW for ; Sat, 7 Dec 2024 09:56:50 +0000 (UTC) (envelope-from furaisanjin@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=XTfMgKH6; spf=pass (mx1.freebsd.org: domain of furaisanjin@gmail.com designates 2a00:1450:4864:20::631 as permitted sender) smtp.mailfrom=furaisanjin@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ej1-x631.google.com with SMTP id a640c23a62f3a-aa662795ca3so26149166b.1 for ; Sat, 07 Dec 2024 01:56:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733565408; x=1734170208; darn=freebsd.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=1zHN5QXHNFEzZr0ZEQOYEMXfGE9Lwp/ZO++/fXoPiYM=; b=XTfMgKH6FxkB4FxpkXuKEs7/yPDnQObhkeQkOdy1JbGkz73E6wA9S3jnkD5qGC2a6e SQONQO4idp7O4qAiaO/qMzY0ZBkZK2CS2AftG1L6m27DUUb5QnROOubvlhJOO0U/qM9g svltJkzI2SxaKLOSPmdRmZImqXSdQDDu9dYve300G4bFEbpixVQ0+3nxbXrFky59SqYS 73U4V30LnGu25ZFJ/ma2hA6VdSB2HhzwX9DuFcHUPkG/lzz1MFq7DGyWF5jBvZwje+SX cabrPT8ikvhy/ZEWRYq/m0wMnyPuNtX8bgtJ8bRwgdY5WyXBN4YoDEqM+YFJpu4GWY1p R5oA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733565408; x=1734170208; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=1zHN5QXHNFEzZr0ZEQOYEMXfGE9Lwp/ZO++/fXoPiYM=; b=Eknj8PF9cRv3crJkyqH3Zt8Ra0KCDoRXjbL+5fnO4Sqf6Rhi1FDv9+i7i6Cgf7Xg0z detgiZshj0fCXqDkr/89LDrz59M5rimebkw5XWVHF2nQEfpXbive7eSoMmudZJVLf9sE Ljx6vE/bPFr9tzY+qMe0HoQjkOshyv11bNtXC0c9MtQ8ZK8NxtS4zjIDynK3C+jyYQ+h tH32n30937/awxjEOmVzunuTTJ8t4OQqUeBKluykb7ju7wj67+y/1938nHQw5wE2fhSn upNNcnOeeCgvQvikcI6EZeGuuP1aPqp93KRcQrWyZbKRnk7dSVswDB5iq5br9auM/fGx 0QhQ== X-Gm-Message-State: AOJu0Yw7VI29JeyOA1r226xhVMSc+3txt0DtukF/R1kp31dcY9/NPc7V yXdow4DkSM27XWN5HAEI++wm7wf3q+Nr9PicdpOFXSOKmhqdpbmx08agLMGrktNiISnnkev3rol i9pV/F++71zAS6owt5X58i2lLeRSFfQp3 X-Gm-Gg: ASbGncuqTGhjdttha36XXMY7nhSFSy8h2EFVu4pnswDUNcrGKm3F5gU1V6/S1DoUzbz +uvfFEE78+v9yX+1q7sSh9kkLbL+hmSNQ X-Google-Smtp-Source: AGHT+IEISp1iI8diwPWM6PRfc1LXtbko4bF/mGAsFE7ho8807SYFEuytcuLNwUdfjAJRWv4z9RIY+oDsltfVJy75yqQ= X-Received: by 2002:a17:906:3ca9:b0:a9a:616c:459e with SMTP id a640c23a62f3a-aa637621b57mr561896466b.27.1733565407825; Sat, 07 Dec 2024 01:56: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: =?UTF-8?B?6aKo5L6G5pWj5Lq6?= Date: Sat, 7 Dec 2024 18:56:11 +0900 Message-ID: Subject: DS1307 on rpi4B To: FreeBSD ARM List Content-Type: multipart/alternative; boundary="00000000000054161c0628ab26d8" X-Spamd-Result: default: False [-3.60 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.60)[-0.599]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MISSING_XM_UA(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::631:from] X-Rspamd-Queue-Id: 4Y53SL4hJvz4PZW X-Spamd-Bar: --- --00000000000054161c0628ab26d8 Content-Type: text/plain; charset="UTF-8" Hello all, I'm trying connect DS1307 on rpi4B (8M). I'm not sure how much I can rely on the description in https://github.com/raspberrypi/firmware/tree/master/boot/overlays because I don't know the difference between linux boot loader and FreeBSD one. I want to connect DS1307 on GPIO12/13 pin as i2c5 so I assumed i2c-rtc could be used so that I added one line in config.txt like below. dtoverlay=i2c-rtc,ds1307,i2c5,addr=0x68 iic1 is detected at boot but it can't talk to DS1307. # dmesg | egrep iic\|ds1307 iichb0: mem 0x7e804000-0x7e804fff irq 27 on simplebus0 iichb1: mem 0x7e205a00-0x7e205bff irq 52 on simplebus0 iicbus0: on iichb0 iic0: on iicbus0 iicbus1: on iichb1 iic1: on iicbus1 ds13070: at addr 0xd0 on iicbus1 ds13070: is_dev_time_valid: cannot read from RTC: 35 ds13070: WARNING: RTC clock stopped, check the battery. ds13070: registered as a time-of-day clock, resolution 1.000000s ds13070: ds1307_gettime: cannot read from RTC: 35 ds13070: ds1307_settime: cannot write to RTC: 35 The command "i2c -s -v -f /dev/iic1" can't detect anything at all. The pin function doesn't seem to be correct. # sysctl -a dev.gpio.0.pin|grep 1[23] dev.gpio.0.pin.13.function: input dev.gpio.0.pin.12.function: input If I set alt5 on these pins by sysctl and change pin configuration by gpioctl to enable internal pullup, iic1 works fine. --- for p in 12 13 do sysctl dev.gpio.0.pin.$p.function=alt5 gpioctl -c $p PU done i2c -s -v -f /dev/iic1 /root/src/ds1307 -r -a 0x68 -f /dev/iic1 --- I'm not familiar with dts stuff but I wrote overlay dts like this. /dts-v1/; /plugin/; / { compatible = "raspberrypi,4-model-b", "brcm,bcm2711"; fragment@0 { target = <&i2c5>; __overlay__ { brcm,pins = <12 13>; brcm,function = <2>; brcm,pull = <2 2>; status = "okay"; }; }; }; However this doesn't work at all. How can I configure gpio12/13 for i2c5? Best regards, furaisanjin --00000000000054161c0628ab26d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello all,

I'm trying connect DS1307 on rpi4B (8M). I'm not s= ure how much I can rely on the description in https://= github.com/raspberrypi/firmware/tree/master/boot/overlays because I don= 't know the difference between linux boot loader and FreeBSD one.
=

I want to connect DS1307 on GPIO12/13 pin as i2c5 so I = assumed i2c-rtc could be used so that I added one line in config.txt like b= elow.

dtoverlay=3Di2c-rtc,ds1307,i2c5,addr=3D0x68<= /div>

iic1 is detected at boot but it can't talk to = DS1307.

# dmesg | egrep iic\|ds1307
iichb0: <= ;BCM2708/2835 BSC controller> mem 0x7e804000-0x7e804fff irq 27 on simple= bus0
iichb1: <BCM2708/2835 BSC controller> mem 0x7e205a00-0x7e205b= ff irq 52 on simplebus0
iicbus0: <OFW I2C bus> on iichb0
iic0: = <I2C generic I/O> on iicbus0
iicbus1: <OFW I2C bus> on iichb= 1
iic1: <I2C generic I/O> on iicbus1
ds13070: <Dallas DS1307= > at addr 0xd0 on iicbus1
ds13070: is_dev_time_valid: cannot read fro= m RTC: 35
ds13070: WARNING: RTC clock stopped, check the battery.
ds1= 3070: registered as a time-of-day clock, resolution 1.000000s
ds13070: d= s1307_gettime: cannot read from RTC: 35
ds13070: ds1307_settime: cannot = write to RTC: 35

The command "i2c -s -v -f /d= ev/iic1" can't detect anything at all. The pin function doesn'= t seem to be correct.
# sysctl -a dev.gpio.0.pin|grep = 1[23]
dev.gpio.0.pin.13.function: input
dev.gpio.0.pin.12.func= tion: input

If I set alt5 on these pins by sysctl = and change pin configuration by gpioctl to enable internal pullup, iic1 wor= ks fine.
---
for p in 12 13
do
=C2= =A0 sysctl dev.gpio.0.pin.$p.function=3Dalt5
=C2=A0 gpioctl -c $p PU
= done
i2c -s -v -f /dev/iic1
/root/src/ds1307 -r -a 0x68 -f /dev/iic1<= /div>
---

I'm not familiar with dts stuff = but I wrote overlay dts like this.
/dts-v1/;
/plugin/;
/ = =C2=A0{

=C2=A0 =C2=A0 =C2=A0 =C2=A0 compatible =3D "raspberrypi= ,4-model-b", "brcm,bcm2711";
=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 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 target =3D <&i2c5>;
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 __overla= y__ {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 brcm,pins =3D <12 13>;
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 brcm,function = =3D <2>;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 brcm,pull =3D <2 2>;
=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 };
};
However thi= s doesn't work at all. How can I configure gpio12/13 for i2c5?

Best regards,
furaisanjin


--00000000000054161c0628ab26d8-- From nobody Sat Dec 7 10:03:06 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Y53bf3cGJz5gr96 for ; Sat, 07 Dec 2024 10:03:10 +0000 (UTC) (envelope-from furaisanjin@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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Y53bd2jGvz4Q35 for ; Sat, 7 Dec 2024 10:03:09 +0000 (UTC) (envelope-from furaisanjin@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=MhSP1ggp; spf=pass (mx1.freebsd.org: domain of furaisanjin@gmail.com designates 2a00:1450:4864:20::635 as permitted sender) smtp.mailfrom=furaisanjin@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-aa549d9dffdso415682266b.2 for ; Sat, 07 Dec 2024 02:03:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733565787; x=1734170587; darn=freebsd.org; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=3F42VOjgaf3xo0jT5ZzHSyM/py8y3lg3Ea5lK3NBC8s=; b=MhSP1ggpQxv8oYMOb4b94euV5UmdWq2vt2uDFWeZhP6lhz+2xtjSLpEv6cMN8o37C7 6FiYSuH1j7fOzYanD9sSHst+d5shes/1ISry31+wzymXD3gCeti4zQitLJDhQxzwfHxy hyeHQeKidq0YU8nCdAXHg8Nrq3K8OTSxHnhPK+wqdeslK7xoAys1p70zP4tPpEvpHxY5 dAIVgOan69Y8GIy7joznEknj1cUVX+0hd2e26Fzn1nepVBh8UGfn/Wmu76CsKN40w2gG Jm8dCk2j3fEJKOVLexNvEdztMA0u1Q84wcTlwvhYk77qZpgy7t2lE9P4hdq/SKVcG19Q uPcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733565787; x=1734170587; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=3F42VOjgaf3xo0jT5ZzHSyM/py8y3lg3Ea5lK3NBC8s=; b=ivARiOKuKmC8GB5Dy54wQTGIOvO0fh6rYmTyWcMW4QejMIqM3xPu+wGP1jdF2G93Bd ix6YVs9C6+WBIoBpoulSwbPU615iEslrkAkTbeUuS34lHrWmYz7VdHMxJod3+HoWvqMo 9HkgYwlnUqlYNArKX6bMUsYPjfpotET+o3+C5RDz5vtqnB0gisHJ2py7QJfVPYyAHyF3 Hfw6CdMmDWxY3TxYgneFZISzJSmwXQLkmg21XMWzC6KdqoQTWxAfnuie5HVrYsVm6CUP pV5PtrUuyHpaepThFntzblOV/LnKmBr1BHW3nVMR1VN/Qp8lIacpsh4Ak91/jYff2VP8 qbcQ== X-Gm-Message-State: AOJu0YxHjvtBzkgCVXO8E/elKeSBYr/zGdyDVnMt6DFJNXU3CYa+08Ee F19WbZYtnh+QDSjUPf23jQmHsRLyA9+EfvIpcRXboWiCrcI6XR9fregdGRc+KrN+oAvIYXb1HUa RwLbC8Qnt9W8i5iSR/2ig3tEEPNUAT+74xSs= X-Gm-Gg: ASbGnctuuQEtrhXGIXe76Y8nO5r1rKfKTRgKf9d6iGo6fXWNaMTF0rfwYyg+Ai9xinP ClAl3Lu98KG5KsNcB+HlKIA4mjxQXYOtO X-Google-Smtp-Source: AGHT+IHcGfZN/948dU7HNf8dcibizVfn1uWEo8C1P4+MC2FzNZl60jpxMEoSEZS9TllZl/2cSpHx0dcDZJ/3R1xVjgo= X-Received: by 2002:a17:906:32d0:b0:aa6:1c4b:9c5b with SMTP id a640c23a62f3a-aa639fa5cfamr367218966b.7.1733565786918; Sat, 07 Dec 2024 02:03:06 -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 Received: by 2002:a05:7412:4e1b:b0:139:4d0f:562f with HTTP; Sat, 7 Dec 2024 02:03:06 -0800 (PST) In-Reply-To: References: From: =?UTF-8?B?6aKo5L6G5pWj5Lq6?= Date: Sat, 7 Dec 2024 19:03:06 +0900 Message-ID: Subject: Re: DS1307 on rpi4B To: FreeBSD ARM List Content-Type: multipart/alternative; boundary="000000000000ec99a60628ab3c73" X-Spamd-Result: default: False [-3.53 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.53)[-0.534]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCPT_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; MID_RHS_MATCH_FROMTLD(0.00)[]; MISSING_XM_UA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::635:from] X-Rspamd-Queue-Id: 4Y53bd2jGvz4Q35 X-Spamd-Bar: --- --000000000000ec99a60628ab3c73 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I forgot mentioning the FreeBSD version. I=E2=80=99m still using 14.1. 2024=E5=B9=B412=E6=9C=887=E6=97=A5=E5=9C=9F=E6=9B=9C=E6=97=A5 =E9=A2=A8=E4= =BE=86=E6=95=A3=E4=BA=BA : > Hello all, > > I'm trying connect DS1307 on rpi4B (8M). I'm not sure how much I can rely > on the description in https://github.com/raspberrypi/firmware/tree/ > master/boot/overlays because I don't know the difference between linux > boot loader and FreeBSD one. > > I want to connect DS1307 on GPIO12/13 pin as i2c5 so I assumed i2c-rtc > could be used so that I added one line in config.txt like below. > > dtoverlay=3Di2c-rtc,ds1307,i2c5,addr=3D0x68 > > iic1 is detected at boot but it can't talk to DS1307. > > # dmesg | egrep iic\|ds1307 > iichb0: mem 0x7e804000-0x7e804fff irq 27 on > simplebus0 > iichb1: mem 0x7e205a00-0x7e205bff irq 52 on > simplebus0 > iicbus0: on iichb0 > iic0: on iicbus0 > iicbus1: on iichb1 > iic1: on iicbus1 > ds13070: at addr 0xd0 on iicbus1 > ds13070: is_dev_time_valid: cannot read from RTC: 35 > ds13070: WARNING: RTC clock stopped, check the battery. > ds13070: registered as a time-of-day clock, resolution 1.000000s > ds13070: ds1307_gettime: cannot read from RTC: 35 > ds13070: ds1307_settime: cannot write to RTC: 35 > > The command "i2c -s -v -f /dev/iic1" can't detect anything at all. The pi= n > function doesn't seem to be correct. > # sysctl -a dev.gpio.0.pin|grep 1[23] > dev.gpio.0.pin.13.function: input > dev.gpio.0.pin.12.function: input > > If I set alt5 on these pins by sysctl and change pin configuration by > gpioctl to enable internal pullup, iic1 works fine. > --- > for p in 12 13 > do > sysctl dev.gpio.0.pin.$p.function=3Dalt5 > gpioctl -c $p PU > done > i2c -s -v -f /dev/iic1 > /root/src/ds1307 -r -a 0x68 -f /dev/iic1 > --- > > I'm not familiar with dts stuff but I wrote overlay dts like this. > /dts-v1/; > /plugin/; > / { > > compatible =3D "raspberrypi,4-model-b", "brcm,bcm2711"; > fragment@0 { > target =3D <&i2c5>; > __overlay__ { > brcm,pins =3D <12 13>; > brcm,function =3D <2>; > brcm,pull =3D <2 2>; > status =3D "okay"; > }; > > }; > }; > However this doesn't work at all. How can I configure gpio12/13 for i2c5? > > Best regards, > furaisanjin > > > --000000000000ec99a60628ab3c73 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I forgot mentioning the FreeBSD version. I=E2=80=99m still using 14.1.
<= br>2024=E5=B9=B412=E6=9C=887=E6=97=A5=E5=9C=9F=E6=9B=9C=E6=97=A5 =E9=A2=A8= =E4=BE=86=E6=95=A3=E4=BA=BA <fu= raisanjin@gmail.com>:
Hello all,

=
I'm trying connect DS1307 on rpi4B (8M). I'm not sure how much= I can rely on the description in https://github.com/<= wbr>raspberrypi/firmware/tree/master/boot/overlays because I don&#= 39;t know the difference between linux boot loader and FreeBSD one.

I want to connect DS1307 on GPIO12/13 pin as i2c5 so I as= sumed i2c-rtc could be used so that I added one line in config.txt like bel= ow.

dtoverlay=3Di2c-rtc,ds1307,i2c5,addr=3D0x= 68

iic1 is detected at boot but it can't talk = to DS1307.

# dmesg | egrep iic\|ds1307
iichb0: = <BCM2708/2835 BSC controller> mem 0x7e804000-0x7e804fff irq 27 on sim= plebus0
iichb1: <BCM2708/2835 BSC controller> mem 0x7e205a00-0x7e2= 05bff irq 52 on simplebus0
iicbus0: <OFW I2C bus> on iichb0
iic= 0: <I2C generic I/O> on iicbus0
iicbus1: <OFW I2C bus> on ii= chb1
iic1: <I2C generic I/O> on iicbus1
ds13070: <Dallas DS1= 307> at addr 0xd0 on iicbus1
ds13070: is_dev_time_valid: cannot read = from RTC: 35
ds13070: WARNING: RTC clock stopped, check the battery.
= ds13070: registered as a time-of-day clock, resolution 1.000000s
ds13070= : ds1307_gettime: cannot read from RTC: 35
ds13070: ds1307_settime: cann= ot write to RTC: 35

The command "i2c -s -v -f= /dev/iic1" can't detect anything at all. The pin function doesn&#= 39;t seem to be correct.
# sysctl -a dev.gpio.0.pin|gr= ep 1[23]
dev.gpio.0.pin.13.function: input
dev.gpio.0.pin.12.f= unction: input

If I set alt5 on these pins by sysc= tl and change pin configuration by gpioctl to enable internal pullup, iic1 = works fine.
---
for p in 12 13
do
= =C2=A0 sysctl dev.gpio.0.pin.$p.function=3Dalt5
=C2=A0 gpioctl -c $= p PU
done
i2c -s -v -f /dev/iic1
/root/src/ds1307 -r -a 0x68 -f /d= ev/iic1
---

I'm not familiar with dt= s stuff but I wrote overlay dts like this.
/dts-v1/;
/plugin/;=
/ =C2=A0{

=C2=A0 =C2=A0 =C2=A0 =C2=A0 compatible =3D "raspb= errypi,4-model-b", "brcm,bcm2711";
=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 =C2=A0 =C2=A0 =C2=A0 =C2=A0 target =3D <&i2c5>;
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =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 brcm,pins =3D <12 13>;
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 brcm,fun= ction =3D <2>;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 brcm,pull =3D <2 2>;
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 s= tatus =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 };
};
Howe= ver this doesn't work at all. How can I configure gpio12/13 for i2c5?

Best regards,
furaisanjin

<= /div>

--000000000000ec99a60628ab3c73-- From nobody Sat Dec 7 13:23:04 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Y582p5ntQz4kw55 for ; Sat, 07 Dec 2024 13:23:30 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (midget.dons.net.au [IPv6:2403:580d:ae98:0:225:90ff:fe47:39b4]) by mx1.freebsd.org (Postfix) with ESMTP id 4Y582p12vmz4fs2 for ; Sat, 7 Dec 2024 13:23:29 +0000 (UTC) (envelope-from darius@dons.net.au) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (unknown [IPv6:2403:580d:ae98:0:e580:69e6:c18e:182f]) by midget.dons.net.au (Postfix) with ESMTPSA id 54FEB74E342; Sat, 07 Dec 2024 23:53:15 +1030 (ACDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dons.net.au; s=default; t=1733577797; bh=xkctXBxZMVNEJsCVXts2S5/H+Dh10uuusQkpiR0Qkwc=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=bS6tiXY8KNCibKv6qsEgm8iQcIDYHq4HbNa9XPcbwZIRVbuAUV1ZPzSa3B7oDQWSh VA+oZDq6FhX51DtTKtWPxuic266YOL/UgY88QUF/8j4YHhz5SpdYdX09SAk1LZ/wW1 FQUNLWaUzDmyZaqQHxCIMn1q8Q9pmUIy8L6UwZjG3petUVbwxx+pg0/Bg9dDWJ8dnh pVZOZ4a2oCtBLsU8t1hwrY7f139Y7VKYvcgqsny1JDkeNDLcrc4hubZCnk+hwKu9BH jZH9ZQsHRcX9jOkg5XVhRCWatCkgeDyrYaRlmztHUrdebFWfL5PTjocWm9HBaE93Uy cluSxpjAx+vtQ== 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 \(3826.200.121\)) Subject: Re: DS1307 on rpi4B From: Daniel O'Connor In-Reply-To: Date: Sat, 7 Dec 2024 23:53:04 +1030 Cc: FreeBSD ARM List Content-Transfer-Encoding: quoted-printable Message-Id: <431FB386-F515-4D77-A855-18055A48E432@dons.net.au> References: To: =?utf-8?B?6aKo5L6G5pWj5Lq6?= X-Mailer: Apple Mail (2.3826.200.121) X-Rspamd-Action: no action X-Rspamd-Server: midget.dons.net.au X-Spam-Status: No, score=-1.10 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:4764, ipnet:2403:5800::/27, country:AU] X-Rspamd-Queue-Id: 4Y582p12vmz4fs2 X-Spamd-Bar: ---- > On 7 Dec 2024, at 20:26, =E9=A2=A8=E4=BE=86=E6=95=A3=E4=BA=BA = wrote: > I'm trying connect DS1307 on rpi4B (8M). I'm not sure how much I can = rely on the description in = https://github.com/raspberrypi/firmware/tree/master/boot/overlays = because I don't know the difference between linux boot loader and = FreeBSD one. >=20 > I want to connect DS1307 on GPIO12/13 pin as i2c5 so I assumed i2c-rtc = could be used so that I added one line in config.txt like below. >=20 > dtoverlay=3Di2c-rtc,ds1307,i2c5,addr=3D0x68 I have the following in /boot/msdos/overlays/pijuice.dtso (which needs = to be compiled to a dtbo): // Definition for RPi3 I2C based Real Time Clock /dts-v1/; /plugin/; / { compatible =3D "brcm,bcm2835"; fragment@0 { target =3D <&i2c1>; __overlay__ { #address-cells =3D <1>; #size-cells =3D <0>; status =3D "okay"; ds1307: ds1307@68 { compatible =3D "maxim,ds1307"; reg =3D <0x68>; status =3D "okay"; }; }; }; __overrides__ { ds1307 =3D <&ds1307>,"status"; }; }; And in /boot/msdos/config.txt: [all] ... # DS1307 RTC dtoverlay=3Dds1307 [pi4] gpio=3D2,3=3Da0 I got the last line from = https://lists.freebsd.org/pipermail/freebsd-arm/2021-May/023713.html After that=20 sudo i2c -f /dev/iic0 -m tr -s Shows the device. Also, be aware that currently the I2C frequency is quite a bit higher = than it should be when the CPU is clocked at the maximum as the divisors = are calculated based on the default clock. This doesn't seem to affect = the DS1307 even though it is only rated for 100kHz. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From nobody Sun Dec 8 02:05:38 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Y5Syy4KCCz5frNH for ; Sun, 08 Dec 2024 02:06:18 +0000 (UTC) (envelope-from furaisanjin@gmail.com) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Y5Syy2L13z4kkm for ; Sun, 8 Dec 2024 02:06:18 +0000 (UTC) (envelope-from furaisanjin@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-wr1-x430.google.com with SMTP id ffacd0b85a97d-3862df95f92so1443773f8f.2 for ; Sat, 07 Dec 2024 18:06:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733623576; x=1734228376; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=MnkagG7EzRpVi5+Me1cPBgXV/AvZ8Z+cs55cSG7c3So=; b=IT6sV49PbQH/Y0aRbux9UFqRKT7jXgQxlCvvhBs9seYjEMpLIlH5gz/SeKcJ7rKytC iQUOf09PpyREA7Z1fBc+SxRrRtCIEhVv5L7FP8DyDaWzNLUQ4kXJy2TTX+4q6Rn9xTtY nHlYCDp31G+S5oDVzoUmqEAYjV0ag0dd9NJRb8slo1eUwRkObRkJgMF2dq7UvlBv3hxq OL4p90o9LQiw7d1qVNmTFF/H7Em5Kc6mJHJT1XMDeNEd415Pr1CfIlLjBgLn8skuN1// k8+hrJh0boQIHexAfBBfXCMGZU0vWJgd+UqUMgZIfoM1efmTAJVDzRbDfMeXcQbfZ237 0X3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733623576; x=1734228376; 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=MnkagG7EzRpVi5+Me1cPBgXV/AvZ8Z+cs55cSG7c3So=; b=Z0bhvkf0IgpuE1XENFguAT7Vui3A+2A9r0RvgQd/GNpK7YzjAA2Elwb98+0qj9ngQ9 DcII8T6gskEG2rJRW5HAd9J61CrBWih/4UNC+QW/58j52yKrQbb4qvGYa6SK2U6hPM17 lRtC6H8HJmb63xysKk4Mvp2CtzjHKQHY86XbcmoYSyvkcB18wR3OSAIrEbYRWVQM2nqt SCo1Nt4fEVBhenwcZQ01VtOpfpl7GjxtYQyUVXMNSB1qy1OxhodT/T9/ZE7nf/9BZER5 xg+s1t4jWnzIrNUPup9+iwqCkiMnYeAxRZXFJFPpAVivUxOL3crT0SiKlKIGOUtdpspw 4DvA== X-Gm-Message-State: AOJu0YzQMRULI3ajOtEwTTaSDOpRgL34QsLbIucSb6UCBw1m1Kijue5e 57eUjMnWZzTvdXWm6VRVEJzuAI//ejzVoq7u8vJEIPCGv97h6TR83epQuPsjCDEGMK/+tzNMkmc pnBHUm/+Tc3a7/dlExMwuJju72ljm+Lqr0xM= X-Gm-Gg: ASbGncuEZ/VgO9J6wYjdlS7lEBLk7PBng1Ru4E7kv7O/IOlr78/+puSzE+lKZCBG8jI VHb9rF99ODZOZJLxPb7tG97y7oTaYm+S9 X-Google-Smtp-Source: AGHT+IF+5qzEqt62wqNrKIpUzexFGlUv0Qj1eI5P+wT5ASTwCM76TMTLYpg5kH9iIUrEpvaI+sFe3FmFcDt3DXssRhM= X-Received: by 2002:a05:6000:144a:b0:385:f8bd:6e80 with SMTP id ffacd0b85a97d-3862b3e4458mr6377038f8f.56.1733623575362; Sat, 07 Dec 2024 18:06:15 -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: <431FB386-F515-4D77-A855-18055A48E432@dons.net.au> In-Reply-To: <431FB386-F515-4D77-A855-18055A48E432@dons.net.au> From: =?UTF-8?B?6aKo5L6G5pWj5Lq6?= Date: Sun, 8 Dec 2024 11:05:38 +0900 Message-ID: Subject: Re: DS1307 on rpi4B To: "Daniel O'Connor" Cc: FreeBSD ARM List Content-Type: multipart/alternative; boundary="00000000000062497a0628b8b186" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4Y5Syy2L13z4kkm X-Spamd-Bar: ---- --00000000000062497a0628b8b186 Content-Type: text/plain; charset="UTF-8" Hello Daniel. Thank you for the suggestion. I created dtso file for my HW configuration like this. /dts-v1/; /plugin/; / { compatible = "brcm,bcm2835"; fragment@0 { target = <&i2c5>; __overlay__ { #address-cells = <1>; #size-cells = <0>; status = "okay"; ds1307: ds1307@68 { compatible = "dallas,ds1307"; reg = <0x68>; status = "okay"; }; }; }; __overrides__ { ds1307 = <&ds1307>,"status"; }; }; I modified config.txt to load this dtbo and add one more line to set GPIO pins in [pi4] gpio=12,13=a5,pu This works fine and RTC starts working. One strange thing is that "gpioctl -l -v" doesn't show correct pin setting somehow. I assumed there should be PU on pin 12 and 13. pin 12: 1 pin 12<>, caps: pin 13: 1 pin 13<>, caps: Best regards, furaisanjin --00000000000062497a0628b8b186 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+PGRpdiBkaXI9Imx0ciI+PGRpdj5IZWxsbyBEYW5pZWwuPC9kaXY+PGRp dj48YnI+PC9kaXY+PGRpdj5UaGFuayB5b3UgZm9yIHRoZSBzdWdnZXN0aW9uLiBJIGNyZWF0ZWQg ZHRzbyBmaWxlIGZvciBteSBIVyBjb25maWd1cmF0aW9uIGxpa2UgdGhpcy48L2Rpdj48ZGl2Pjxi cj48L2Rpdj48ZGl2Pi9kdHMtdjEvOzxicj4vcGx1Z2luLzs8YnI+PGJyPi8gezxicj7CoCDCoCDC oCDCoCBjb21wYXRpYmxlID0gJnF1b3Q7YnJjbSxiY20yODM1JnF1b3Q7Ozxicj48YnI+wqAgwqAg wqAgwqAgZnJhZ21lbnRAMCB7PGJyPsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRhcmdldCA9ICZs dDsmYW1wO2kyYzUmZ3Q7Ozxicj7CoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBfX292ZXJsYXlfXyB7 PGJyPsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICNhZGRyZXNzLWNlbGxzID0g Jmx0OzEmZ3Q7Ozxicj7CoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAjc2l6ZS1j ZWxscyA9ICZsdDswJmd0Ozs8YnI+wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg c3RhdHVzID0gJnF1b3Q7b2theSZxdW90Ozs8YnI+wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgZHMxMzA3OiBkczEzMDdANjggezxicj7CoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBjb21wYXRpYmxlID0gJnF1b3Q7ZGFsbGFzLGRzMTMwNyZx dW90Ozs8YnI+wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg cmVnID0gJmx0OzB4NjgmZ3Q7Ozxicj7CoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCBzdGF0dXMgPSAmcXVvdDtva2F5JnF1b3Q7Ozxicj7CoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB9Ozxicj7CoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB9Ozxi cj7CoCDCoCDCoCDCoCB9Ozxicj7CoCDCoCDCoCDCoCBfX292ZXJyaWRlc19fIHs8YnI+wqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgZHMxMzA3ID0gJmx0OyZhbXA7ZHMxMzA3Jmd0OywmcXVvdDtzdGF0 dXMmcXVvdDs7PGJyPsKgIMKgIMKgIMKgIH07PGJyPn07PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRp dj5JIG1vZGlmaWVkIGNvbmZpZy50eHQgdG8gbG9hZCB0aGlzIGR0Ym8gYW5kIGFkZCBvbmUgbW9y ZSBsaW5lIHRvIHNldCBHUElPIHBpbnMgaW4gW3BpNF08YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+ PGRpdj5ncGlvPTEyLDEzPWE1LHB1PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5UaGlzIHdvcmtz IGZpbmUgYW5kIFJUQyBzdGFydHMgd29ya2luZy4gT25lIHN0cmFuZ2UgdGhpbmcgaXMgdGhhdCAm cXVvdDtncGlvY3RsIC1sIC12JnF1b3Q7IGRvZXNuJiMzOTt0IHNob3cgY29ycmVjdCBwaW4gc2V0 dGluZyBzb21laG93LiBJIGFzc3VtZWQgdGhlcmUgc2hvdWxkIGJlIFBVIG9uIHBpbiAxMiBhbmQg MTMuPGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+cGluIDEyOiAxIMKgIMKgIMKgIHBpbiAx MiZsdDsmZ3Q7LCBjYXBzOiZsdDtJTixPVVQsUFUsUEQsSU5UUkxMLElOVFJMSCxJTlRSRVIsSU5U UkVGLElOVFJFQiZndDs8YnI+cGluIDEzOiAxIMKgIMKgIMKgIHBpbiAxMyZsdDsmZ3Q7LCBjYXBz OiZsdDtJTixPVVQsUFUsUEQsSU5UUkxMLElOVFJMSCxJTlRSRVIsSU5UUkVGLElOVFJFQiZndDs8 YnI+PC9kaXY+PC9kaXY+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIGdtYWlsX3F1b3RlX2Nv bnRhaW5lciI+QmVzdCByZWdhcmRzLDwvZGl2PjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIGdtYWls X3F1b3RlX2NvbnRhaW5lciI+ZnVyYWlzYW5qaW48YnI+PC9kaXY+PC9kaXY+DQo= --00000000000062497a0628b8b186-- From nobody Sun Dec 8 03:40:54 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Y5W4V2MmFz5fyVL for ; Sun, 08 Dec 2024 03:41:14 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (midget.dons.net.au [IPv6:2403:580d:ae98:0:225:90ff:fe47:39b4]) by mx1.freebsd.org (Postfix) with ESMTP id 4Y5W4T64VPz4sfN for ; Sun, 8 Dec 2024 03:41:13 +0000 (UTC) (envelope-from darius@dons.net.au) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (unknown [IPv6:2403:580d:ae98:0:1d3:8d36:7882:e071]) by midget.dons.net.au (Postfix) with ESMTPSA id 4B1FA74F97C; Sun, 08 Dec 2024 14:11:05 +1030 (ACDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dons.net.au; s=default; t=1733629267; bh=pOeK9ThzDksMGfRtlEIxtq/5YCu7M6ffMcrYXyUBM9o=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=ecoFngCMl8G5w3ObXqyLfd2X+Mo94ORyonYiK6xzmBQiI8FMeioQbD0N3E3r0caJ0 9Na2AtiUSzuyAhBL7w7h+fZu/UMQZ89ymzanBc/eDJvikYyEdX1zD6CuYw4ZH68YZu OPlwbd/HoS6dgmEBipfxVe7UVIUyl3AhPZZa8fraoIQnj8u2WAcXGfOemFnjSaMZyr b2r3726OfiN5RuFRh1hIQdx51TOlSfbYaUdlSq7gvXKGxnOEhe6TdYvouHCSBAepJd fN6gFNcmpMU1Urp9ntwna+C7coYgxMOq0su1SH/KGPMir4pr5gapJzW/nEhGhojD5y aBZRX8S17jIlg== 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 \(3826.200.121\)) Subject: Re: DS1307 on rpi4B From: Daniel O'Connor In-Reply-To: Date: Sun, 8 Dec 2024 14:10:54 +1030 Cc: FreeBSD ARM List Content-Transfer-Encoding: quoted-printable Message-Id: References: <431FB386-F515-4D77-A855-18055A48E432@dons.net.au> To: =?utf-8?B?6aKo5L6G5pWj5Lq6?= X-Mailer: Apple Mail (2.3826.200.121) X-Rspamd-Action: no action X-Rspamd-Server: midget.dons.net.au X-Spam-Status: No, score=-1.10 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:4764, ipnet:2403:5800::/27, country:AU] X-Rspamd-Queue-Id: 4Y5W4T64VPz4sfN X-Spamd-Bar: ---- Hi, > On 8 Dec 2024, at 12:35, =E9=A2=A8=E4=BE=86=E6=95=A3=E4=BA=BA = wrote: > I modified config.txt to load this dtbo and add one more line to set = GPIO pins in [pi4] >=20 > gpio=3D12,13=3Da5,pu >=20 > This works fine and RTC starts working. One strange thing is that = "gpioctl -l -v" doesn't show correct pin setting somehow. I assumed = there should be PU on pin 12 and 13. >=20 > pin 12: 1 pin 12<>, = caps: > pin 13: 1 pin 13<>, = caps: Strange - I don't know if the pull ups on the SoC are suitable for I2C. = The modules I have used have pull ups as real resistors - in internal = pull-ups on SoCs tend to have a pretty broad range due to the way they = are fabricated. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From nobody Sun Dec 8 04:12:29 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Y5WnL3bV2z5g22N for ; Sun, 08 Dec 2024 04:13:10 +0000 (UTC) (envelope-from furaisanjin@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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Y5WnL1C6mz3xCj for ; Sun, 8 Dec 2024 04:13:10 +0000 (UTC) (envelope-from furaisanjin@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-aa1e6ecd353so528081866b.1 for ; Sat, 07 Dec 2024 20:13:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733631188; x=1734235988; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=BEKou0MEFx7pbJGBgKv8XXdWHQSw88paX5Szmt2jDGU=; b=JownywFWG7QVPya7kEi/nn36gcH3cwO2YcFPFpdLZ6+DyNDXbmOvAbZVe2I4ViY4Qt 9gi1xxU+6Vg3ywmL+S9UL+Xb7b1PY4TjxkTmp/wUZsfNQYGI0vSq40kAPRSKlgW0sUMe udTeh9AND066BXfH4QcbXehU0vUPyg3BcbTohR1Sdjc8HsUTKgp7U3vr6xDVQo2RAB1B lnP5Gql8yp+0Mxy73rhy2I3AwV/9QotW9r23hASWcsLz3laQzHUfFscuAoZnxuNht8o7 JHi9hVuTAmYGWpV+Hf2LnHqURczc1UbVt2/q6Mck0J/r4kXKLBbhK/iFa/JWUf8X3MJa FffA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733631188; x=1734235988; 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=BEKou0MEFx7pbJGBgKv8XXdWHQSw88paX5Szmt2jDGU=; b=i5/VzAjHNNI5CLxyzvDEMwDOlMevJV3/ccQdJZ+K6dqo2ytpJXWiWP/gCCbarxUk4U zmkIjpwh4ZDG4DeeWwhERavXrtHaeLlbNG7209wDVP/8wh5wdRnXhfvqQ+qjMFoQz40p PPkWa6CkV8vBDLBtDgMt9RalH84CarT0JGLc8hMI/LrTK06/MSwLlB9AO4/WsRut6KAu 4X8DFcBXyHsis72ntDFyWnTwrj9Xbg1tPkB6iEGwz0NyPA6EUdQ3kxxA6NxiIjO/pJC9 5V1qzMbUt9nfF+3+o1WYYcnXjrdiaD60Rh7pLh5dL6jgaHwJaxDzvVLDyaahjCfcjrGu dblg== X-Gm-Message-State: AOJu0YztXwJz+lm9fAo+ivUv4/EccEBigqerkTs9Ko/6pzPYSqfV5vCC mRp/YVbiFpMcU9BcT7dPbOqjNmJ9S1HwZc/jc1w3dTKkEFrwVQtnpWtGFR5cSZrVjU7XCu76uGr LDRI8xM5ZqI74HKBkjrz9QxdBNBlzuvdAAgQ= X-Gm-Gg: ASbGncvpl6WR+xjaakNr8CfC5CXR+TSQlewQ7RMp7k2vfv/AqA1j38j3cgFb3BvsfoT lpM47fbvXtJVRvSo/bcFWrijsZxAfK8K6 X-Google-Smtp-Source: AGHT+IEZ7q1A6SttLCdYhFTG2Tjk8qQf72EJQEVHUalrpka+Nlz5KKjba/XCPk8KHTkNhTKCitN8F+1/+kTVkLLnuRE= X-Received: by 2002:a05:6402:1913:b0:5d1:1064:326a with SMTP id 4fb4d7f45d1cf-5d3be69a19amr20494518a12.15.1733631187374; Sat, 07 Dec 2024 20:13:07 -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: <431FB386-F515-4D77-A855-18055A48E432@dons.net.au> In-Reply-To: From: =?UTF-8?B?6aKo5L6G5pWj5Lq6?= Date: Sun, 8 Dec 2024 13:12:29 +0900 Message-ID: Subject: Re: DS1307 on rpi4B To: "Daniel O'Connor" Cc: FreeBSD ARM List Content-Type: multipart/alternative; boundary="0000000000001859970628ba775e" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4Y5WnL1C6mz3xCj X-Spamd-Bar: ---- --0000000000001859970628ba775e Content-Type: text/plain; charset="UTF-8" Hello. I'm using this module ( https://www.electronicwings.com/sensors-modules/real-time-clock-rtc-ds1307-module) and there are R2 and R3 for pull-up on the module. The registers are connected to 5V. This probably harms RPI4B because the voltage is 3.3V at RPI4B side. So I removed R2 and R3. That's why internal pull-up is required. Best regards, furaisanjin --0000000000001859970628ba775e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello.

I= 9;m using this module (https://www.electronicwings.com/s= ensors-modules/real-time-clock-rtc-ds1307-module) and there are R2 and = R3 for pull-up on the module. The registers are connected to 5V. This proba= bly harms RPI4B because the voltage is 3.3V at RPI4B side. So I removed R2 = and R3. That's why internal pull-up is required.

Best regards,
furaisanjin

--0000000000001859970628ba775e-- From nobody Sun Dec 8 04:29:17 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Y5X8N3ByXz5g2Mh for ; Sun, 08 Dec 2024 04:29:40 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (midget.dons.net.au [61.245.145.238]) by mx1.freebsd.org (Postfix) with ESMTP id 4Y5X8N08vYz3yv9 for ; Sun, 8 Dec 2024 04:29:40 +0000 (UTC) (envelope-from darius@dons.net.au) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (unknown [IPv6:2403:580d:ae98:0:1d3:8d36:7882:e071]) by midget.dons.net.au (Postfix) with ESMTPSA id A4DAE72DD46; Sun, 08 Dec 2024 14:59:27 +1030 (ACDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dons.net.au; s=default; t=1733632169; bh=KapwP7NOfeRyxfPB2bsljzFIwvS3cPC3deako23B7j0=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=vqNcdUxa77a8770VJr1NN92u+46CnYtOgkjUiMGr8CrjTXOmE0NQ86sCjHO8PYEhb c0DAPAGD3oABa8r0eshWFkMWmRERoaQ7B+7GjDlF/0DQ2gVDHBg2ABAx3OJqa1l/S2 IkGVfDVNMNPwk3wpKGoQcHnQ07c3sp5Kl+qeiTCtqfndg2fwbqmckzS8qyyU7a1Ef7 Gv6WKXF1zz3W8AM80VXF3ENznaR4uFt2d517/AQgO2v2UPSHmpuZexPjgisSKNXMHN q2X5OXkH4QoLz/e11sxDgNxlm5FYXbIa128rVOFvhHCfiY1yczX+lQgvlpmBWRI5gG iAQ4mfd7xqSxg== 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 \(3826.200.121\)) Subject: Re: DS1307 on rpi4B From: Daniel O'Connor In-Reply-To: Date: Sun, 8 Dec 2024 14:59:17 +1030 Cc: FreeBSD ARM List Content-Transfer-Encoding: quoted-printable Message-Id: <9D78A58D-D0C7-4C5C-AF74-F4FABBAEB6C8@dons.net.au> References: <431FB386-F515-4D77-A855-18055A48E432@dons.net.au> To: =?utf-8?B?6aKo5L6G5pWj5Lq6?= X-Mailer: Apple Mail (2.3826.200.121) X-Rspamd-Action: no action X-Rspamd-Server: midget.dons.net.au X-Spam-Status: No, score=-1.10 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:4764, ipnet:61.245.144.0/22, country:AU] X-Rspamd-Queue-Id: 4Y5X8N08vYz3yv9 X-Spamd-Bar: ---- > On 8 Dec 2024, at 14:42, =E9=A2=A8=E4=BE=86=E6=95=A3=E4=BA=BA = wrote: > I'm using this module = (https://www.electronicwings.com/sensors-modules/real-time-clock-rtc-ds130= 7-module) and there are R2 and R3 for pull-up on the module. The = registers are connected to 5V. This probably harms RPI4B because the = voltage is 3.3V at RPI4B side. So I removed R2 and R3. That's why = internal pull-up is required. Ah that is unfortunate. There is 3.3V on the 40 pin RPi header you could connect to R2/R3 (and = cut the connection to 5V obviously). -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum