From owner-freebsd-arm@freebsd.org Sun May 2 02:58:50 2021 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9165D5E4D00 for ; Sun, 2 May 2021 02:58:50 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-21.consmr.mail.gq1.yahoo.com (sonic305-21.consmr.mail.gq1.yahoo.com [98.137.64.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FXrQx1QvGz3k5j for ; Sun, 2 May 2021 02:58:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1619924327; bh=vjkkIEt5RwlwmpGbnYgyrgFrlG89OFamZe277vJOFvc=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=JtLR56AR+uAmFOS3XrDqs6jhHv8ivke3PBeg8o1bUx8jnU/H/dsJWT+upp1cEg0qFtAYPg4D+u9wdAk32RfTLuhyWEsLZA46ir+uTS3Dda3dY9hdsGjbbB8SR+XFAXdC3GnxzzL11c+ZW8xYpP2A4EsehGe/qP/8TIhOXoer7VUQ3hiIOp5n9Q1uQYA6OlYkw/LEX3avfo14Gs0VUjrErXXKyfc1TovYUDSIYKX38wmsx/AHelNjJ5HG4bqGkR7K29TJfuWrj8iFhQ0xVXjKFzAuGtRuB1FTEtE5EiEF1/odXhD2FFFj7T09CwFz6g+j7jilscdor6JCLoSoFhGFow== X-YMail-OSG: tEObGnMVM1nHh2h4GMMWFT963D_aA0m8zJ7h.gbf4DJtQLc7DVsM7MhSR9KFvnL 16jZ0eeNPGbu3k.ykFbk0amZIpVzi_V269xIM.0snIuxW6xwu9cE5PPQ1BO0L4nrNQrpd0SUwyAI dXXOeM2f4MLBjaY5s47cPGrVLGRtBv0.44Q.V1UaXCF15eH5EBVyUoUOKNsUkhL4vhVXzBEI8h_3 UO5_1p14_QnNJD8Y0hF_ct7aO1BBviDk1w9zd_Uzn8Rm6k6VMW8CHrAk6V8IFoNu4CNJIvSHFMNt C.0xpOVVlA6pYMIQfoWBjMw_6fB6cIRfca3BH8HnHS..vAmZEhssQya4GMyXluqxWxUcnfGNKwAV hRsTR3fKxWnRDNQt4qCESnL3YL.kdRchgfBqeuertYrnV_09ss5wcdaWArrPmoQerIEGkYDiNVaG cann_YvJCamIFJJ7j53DElhdkYm87MDNQo036pGtu.b9XfzovqqF2vypBM0e.1dxgSbeG8vzuS1. UFLrOLLrn25VKLYkFZUQmbU12GDwjS26zAEgVHGUTWa6IwBiOaT.epcDuCKBo8i9H8Ww6PZuIHWQ 9AO.wqZcxMijzSNPKbq0lR4sfuRFrYMQa6fBiGFrzkBD.XcrdwbP2a7yUhGeBdsSsCMh54bRiQ4A 9YpWtYF8rAZbLfc0eYhVvppIP0Dw.kDK..bU.VRzncA.61f0a737dAzL.Kgj6bfaKG2tZnvdo5Py LBbuwZRgd9icztCrA7NTKH4ALT95Jrw9vUZkQma3T7KudZbnnl9ktr1LXh0FwCWLYp9EwOkFrXt1 _0cqH5vKvgCcYF2RSjdg4GyR1DwVMK1fmj2ArTQwzQGrTBUQPpD3V_U.3RPVoENhVU18D1NEfpNd gZMx_6JgLeh0.1u9IG5fdCJueOa59C2CrgJz_WasBS8tMii9l5zYuY.dNllGUf9fG.VS5cyUbbOV QxQZ07COqevSmRwyBNBw.5HHUp9iGmsmUavXQ2b64ELiDf.uMp02ex5dYrapJp1y6z0zcMd1_.mR vXOMINeQS8WrwvXl0l9c5nMlTETykjt8V8xeAYL3GubfxLOxVLH.0lP5a6fXkPbUfJuuY_0IJyDH tXa2kL_2VInzFChalx8Xl9Gmjo.T3BlJ_lB71FIPDxf8aEdioQOPOms3fxcT2CWvypG2BHgNWsml MNIdmiyKfIHHglyUf_3dCh7ChGA_pVuRFVcWv5J4zoEUVwg.TA79sMPPp89SLOmIXlni5qTDIjOc 79XvD0XOmBwUQZFk_FacFKu.mjRhAST81cnLURWLZCg2CiXftIvbwTqEz36XpSTq6Csj0M9qpc1C uIcwRitIZTiu88ibZFTd.UyCWil9X31x1B35rb7dp0EsuYxoX8QuaBUmcfdK.IIh1U_4UebQDfvu 1vE23feKrpWfwOdFgB6Z7_tO84FO2xDJVB37mKg.2KVgVcMPIWEho8TZehRNYK_.mUbx5hYNlMs5 anA2dUsvRgFp_ay5WzTRs73ZgHOXtVvqxP9F9ytc_MW7TcYgbT3wrWncAWKEo7ZdZjXXvVcliuW6 Csjg4xiIw2ViHUgY15S7OEDd2eG0ds0UpX0ysvLSsE9pZx2ixGJY_Cs5ApmchKVvaPaw1XXFA96w UtDrTGNnZo6tv2MxBr6V66KAaJ6WYg3EFxhWpdOy0vl.3rrFjCvqXdWLUMdyHBrAcs_GBLc9brOX q6nkCtr6ERNkbplfPLxFVJu_6RIo86gR1cy6nCS9N8emU5aD..2Di5SmpG31_dtFmpsg01GSWC8D iyv9YXYVzhVXc4vN5EzXNEdTzd79exUs68Rgbzek.CLb.KhNaiitkDVrW2.RV9EY4Y2EjTHoDjIF 3US6CSH70IJD3zrhwUmgbMGhkI5705iWBv6LGxvaoMlUYGN9xFB4cr4Fz6zQhXp6TlYYVHlIQ4Za NqMr8J18c7Bo2rjmGFO3PaIbNI0skyjlcA63XGTQL6A696FiVqcQvQ7ZEJtM72zZd1wyrcQMV0mR pQ0VsASkuxZW8bs3zhF1wpPQp6jiE0nmUZuKnL5BVSIA9aLWFyD5ARsNx1JxxWYMbG657bvEXy10 7VMtBU1t1AQjhX3vWz0KOpsHzFfAAwhmfvzCaDyTQ3.F3Q2U.tOp3j4x8gYNc475ZkRzEniU7dCs ip.XkvkS1P.e.jBKDAARVxIUjZvd7ETX51v_qnS2jlNSEF.aJv3ksk0UFvH.HD8q_fUBVVvUHO0. Fbv0aEt.T8c9RC8LKFCFjqyVx1gQZ.ABL3bh.CJ2CJWdY5Dh5LK.3EXwgGdJvC0j3Ju12fyI3SS5 dPBiJbAL5Yvx7fplFyDgO4Nb1ZiYHRFZo6Xp97TPuS1kW75.G_Qx3dC.aWWNsYJ_VMNwzTH8Wwus G6IRAb.9ThF9m28q6r3oqJ1NJYXCUNOYuBNF713nGDSDGfm2z3ABOLZ_uOLvCkzewvq7J5K6qrel Kc6OwKOMA_77mVHoWMRVgUQApLbTk4RvRD7tkLRCRdtO5fHFCMZXR1g-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sun, 2 May 2021 02:58:47 +0000 Received: by kubenode563.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID db08db8a20a76058dbae7ba33afdaf8a; Sun, 02 May 2021 02:58:42 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Subject: Re: I2C/IIC working on RPI4 8GB? From: Mark Millard In-Reply-To: Date: Sat, 1 May 2021 19:58:41 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <8CBBAE44-E736-4DEF-BA60-4D5068D25C15@yahoo.com> References: <1C2DD11C-B1F6-4C2A-9AB0-5F1553520FF5@FreeBSD.org> <20210426161138.a8f44b6e1134f73a411be57d@bidouilliste.com> <47A634E3-4938-4AFC-9341-E480CEBF67FB@FreeBSD.org> <20210428101945.67417ef8eba251dcbcb38078@bidouilliste.com> <486E3EA3-EBAE-492E-B12E-E72E3E3E7B6A@FreeBSD.org> <501CB1C0-73D4-4BEF-A1E6-1F13C02EFA42@FreeBSD.org> To: Mark Murray X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Rspamd-Queue-Id: 4FXrQx1QvGz3k5j X-Spamd-Bar: - X-Spamd-Result: default: False [-1.21 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.64.84:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[0.0.0.3:email,0.0.0.1:email,0.0.0.4:email,0.0.0.0:email,0.0.0.5:email]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(0.29)[0.288]; SPAMHAUS_ZRD(0.00)[98.137.64.84:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.84:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.84:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Porting FreeBSD to ARM processors List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 May 2021 02:58:50 -0000 On 2021-May-1, at 08:31, Mark Millard wrote: > On 2021-May-1, at 04:48, Mark Murray wrote: >=20 >> On 30 Apr 2021, at 15:22, Klaus K=C3=BCchemann wrote: >>>=20 >>>=20 >>> yet another useful document(at least that's what I hope to fix your = usecase) : >>>=20 >>> = https://www.raspberrypi.org/documentation/configuration/config-txt/gpio.md= >>=20 >> BINGO!! >>=20 >> I added >>=20 >> gpio=3D2,3=3Da0 >>=20 >> to my config.txt file and after a reboot, >>=20 >> # i2c -f /dev/iic0 -s worked! >=20 >=20 > Cool. >=20 > But it leaves me wondering what the FreeBSD equivalent > for setting the mode of those 2 gpio's to a0 (or other > alternatives) is supposed to look like (even if such > code would not work as things are in the implementation). >=20 > (But, for me, it is idle wondering.) [I was given a code hint that I've not investigated yet.] But going in a different direction, based on my default context on the local FreeBSD RPI4B 8 GiByte: In BCM2835-ARM-Peripherals.pdf I see that the bits are in: Address Field Name Description Size Read/ Write 0x 7E20 0000 GPFSEL0 GPIO Function Select 0 32 R/W Bit fields: Bit(s) Field Name Description Type Reset 11-9 FSEL3 FSEL3 - Function Select 3 R/W 0 8-6 FSEL2 FSEL2 - Function Select 2 R/W 0 for the 3 bit sequence: 100 =3D GPIO Pin ? takes alternate function 0 (so 0x4 shifted over) With dtdebug enabled in config.txt for the RPi firmware I see: MESS:00:00:06.171556:0: dtdebug: /aliases:i2c_vc=3Di2c0 MESS:00:00:06.179873:0: dtdebug: /__symbols__:i2c_vc=3Di2c0 MESS:00:00:06.185545:0: dtdebug: /__overrides__:i2c_vc=3Di2c0 MESS:00:00:06.194913:0: dtdebug: = /__overrides__:i2c_vc_baudrate=3Di2c0_baudrate MESS:00:00:06.200209:0: dtdebug: /aliases:i2c=3Di2c1 MESS:00:00:06.208333:0: dtdebug: /__symbols__:i2c=3Di2c1 MESS:00:00:06.213770:0: dtdebug: /__overrides__:i2c=3Di2c1 MESS:00:00:06.217250:0: dtdebug: /aliases:i2c_arm=3Di2c1 MESS:00:00:06.225726:0: dtdebug: /__symbols__:i2c_arm=3Di2c1 MESS:00:00:06.231504:0: dtdebug: /__overrides__:i2c_arm=3Di2c1 MESS:00:00:06.241007:0: dtdebug: = /__overrides__:i2c_baudrate=3Di2c1_baudrate MESS:00:00:06.251752:0: dtdebug: = /__overrides__:i2c_arm_baudrate=3Di2c1_baudrate . . . MESS:00:00:06.308655:0: dtparam: i2c_arm=3Don MESS:00:00:06.312366:0: dtdebug: found override i2c_arm MESS:00:00:06.314694:0: dtdebug: override i2c_arm: string target = 'status' . . . MESS:00:00:06.345793:0: dtdebug: Opened overlay file 'overlays/mmc.dtbo' MESS:00:00:06.352119:0: brfs: File read: /mfs/sd/overlays/mmc.dtbo MESS:00:00:06.370052:0: Loaded overlay 'mmc' . . . MESS:00:00:06.417378:0: dtdebug: = merge_fragment(/soc/gpio@7e200000,/fragment@1/__overlay__) MESS:00:00:06.428737:0: dtdebug: = merge_fragment(/soc/gpio@7e200000/mmc_pins,/fragment@1/__overlay__/mmc_pin= s) MESS:00:00:06.435561:0: dtdebug: +prop(brcm,pins) MESS:00:00:06.440871:0: dtdebug: +prop(brcm,function) MESS:00:00:06.445807:0: dtdebug: +prop(brcm,pull) MESS:00:00:06.458675:0: dtdebug: +prop(phandle) MESS:00:00:06.462106:0: dtdebug: merge_fragment() end MESS:00:00:06.465128:0: dtdebug: merge_fragment() end . . . MESS:00:00:06.544997:0: dtdebug: Opened overlay file = 'overlays/disable-bt.dtbo' MESS:00:00:06.551664:0: brfs: File read: = /mfs/sd/overlays/disable-bt.dtbo MESS:00:00:06.593262:0: Loaded overlay 'disable-bt' . . . MESS:00:00:06.721520:0: dtdebug: = merge_fragment(/soc/gpio@7e200000/uart0_pins,/fragment@3/__overlay__) MESS:00:00:06.727770:0: dtdebug: +prop(brcm,pins) MESS:00:00:06.733682:0: dtdebug: +prop(brcm,function) MESS:00:00:06.738585:0: dtdebug: +prop(brcm,pull) MESS:00:00:06.743197:0: dtdebug: merge_fragment() end MESS:00:00:06.762561:0: dtdebug: = merge_fragment(/soc/gpio@7e200000/bt_pins,/fragment@4/__overlay__) MESS:00:00:06.768566:0: dtdebug: +prop(brcm,pins) MESS:00:00:06.774438:0: dtdebug: +prop(brcm,function) MESS:00:00:06.779361:0: dtdebug: +prop(brcm,pull) MESS:00:00:06.784019:0: dtdebug: merge_fragment() end MESS:00:00:06.787886:0: dtdebug: = merge_fragment(/aliases,/fragment@5/__overlay__) MESS:00:00:06.794694:0: dtdebug: +prop(serial0) MESS:00:00:06.800962:0: dtdebug: +prop(serial1) MESS:00:00:06.805366:0: dtdebug: merge_fragment() end Then, based on using: Using DTB provided by EFI at 0x7ef0000. stopping in U-Boot and doing: U-Boot> fdt addr 0x7ef0000 U-Boot> fdt print it provides dtb material from after any dynamic substitutions, not just what is in the .dtb file. Looking I see various alternatives, some of which look to have the 0x4 to be shifted over for gpio2 and for gpio33: . . . i2c1 =3D "/soc/i2c@7e804000"; . . . dpi_gpio0 { brcm,pins =3D <0x00000000 0x00000001 = 0x00000002 0x00000003 0x00000004 0x00000005 0x00000006 0x00000007 = 0x00000008 0x00000009 0x0000000a 0x0000000b 0x0000000c 0x0000000d 0 x0000000e 0x0000000f 0x00000010 0x00000011 0x00000012 0x00000013 = 0x00000014 0x00000015 0x00000016 0x00000017 0x00000018 0x00000019 = 0x0000001a 0x0000001b>; brcm,function =3D <0x00000006>; phandle =3D <0x00000048>; }; . . . (I think the below i2c1_gpio2 indicates alt0) i2c1_gpio2 { brcm,pins =3D <0x00000002 0x00000003>; brcm,function =3D <0x00000004>; phandle =3D <0x00000052>; }; . . . i2c3_gpio2 { phandle =3D <0x0000006d>; pin-sda { function =3D "alt5"; pins =3D "gpio2"; bias-pull-up; }; pin-scl { function =3D "alt5"; pins =3D "gpio3"; bias-disable; }; }; . . . spi3_gpio0 { phandle =3D <0x00000088>; pins-spi { pins =3D "gpio0", "gpio1", = "gpio2", "gpio3"; function =3D "alt3"; }; }; . . . uart2_ctsrts_gpio2 { phandle =3D <0x0000008d>; pin-cts { pins =3D "gpio2"; function =3D "alt4"; bias-pull-up; }; pin-rts { pins =3D "gpio3"; function =3D "alt4"; bias-disable; }; }; . . . dpi_18bit_gpio0 { brcm,pins =3D <0x00000000 0x00000001 = 0x00000002 0x00000003 0x00000004 0x00000005 0x00000006 0x00000007 = 0x00000008 0x00000009 0x0000000a 0x0000000b 0x0000000c 0x0000000d 0 x0000000e 0x0000000f 0x00000010 0x00000011 0x00000012 0x00000013 = 0x00000014 0x00000015>; brcm,function =3D <0x00000006>; phandle =3D <0x00000096>; }; dpi_18bit_gpio2 { brcm,pins =3D <0x00000002 0x00000003 = 0x00000004 0x00000005 0x00000006 0x00000007 0x00000008 0x00000009 = 0x0000000a 0x0000000b 0x0000000c 0x0000000d 0x0000000e 0x0000000f 0 x00000010 0x00000011 0x00000012 0x00000013 0x00000014 0x00000015>; brcm,function =3D <0x00000006>; phandle =3D <0x00000097>; }; . . . spi3_pins { brcm,pins =3D <0x00000001 0x00000002 = 0x00000003>; brcm,function =3D <0x00000007>; phandle =3D <0x00000098>; }; . . . (I think the below i2c1 indicates alt0) i2c1 { brcm,pins =3D <0x00000002 0x00000003>; brcm,function =3D <0x00000004>; brcm,pull =3D <0x00000002>; phandle =3D <0x00000017>; }; . . . i2c1 =3D [00 00 00 35 73 74 61 74 75 73 00]; . . . i2c1_gpio2 =3D "/soc/gpio@7e200000/i2c1_gpio2"; . . . i2c3_gpio2 =3D "/soc/gpio@7e200000/i2c3_gpio2"; . . . uart2_ctsrts_gpio2 =3D = "/soc/gpio@7e200000/uart2_ctsrts_gpio2"; . . . dpi_18bit_gpio2 =3D = "/soc/gpio@7e200000/dpi_18bit_gpio2"; . . . i2c1_pins =3D "/soc/gpio@7e200000/i2c1"; . . . There is sort of an overall alt0 --that omits mention of gpio2 and 3: . . . alt0 { brcm,pins =3D <0x00000004 0x00000005 = 0x00000007 0x00000008 0x00000009 0x0000000a 0x0000000b>; brcm,function =3D <0x00000004>; phandle =3D <0x00000095>; }; . . . alt0 =3D "/soc/gpio@7e200000/alt0"; . . . The same was true with gpio=3D2,3=3Da0 in the config.txt . The only diff reported for the fdt print output was: chosen { - kaslr-seed =3D <0x3bab60e6 0x2352e756>; + kaslr-seed =3D <0x2adcd524 0x37345f4c>; rpi-boardrev-ext =3D <0x00000000>; But I have confirmed a difference via how pins 2 and 3 show up via: # gpioctl -f /dev/gpioc0 -l -v pin 00: 1 pin 0, = caps: pin 01: 1 pin 1, = caps: pin 02: 1 pin 2<>, = caps: pin 03: 1 pin 3<>, = caps: pin 04: 1 pin 4, = caps: pin 05: 1 pin 5, = caps: . . . =46rom the all the above I gather that the right i2c*.dtbo is from: /usr/local/share/rpi-firmware/overlays/i2c1.dtbo (just based on the "i2c1" part of the naming). But the Readme.md for overlays/ reports: Note also that i2c, i2c_arm and i2c_vc are aliases for the = physical interfaces i2c0 and i2c1. Use of the numeric variants is still = possible but deprecated because the ARM/VC assignments differ between = board revisions. The same board-specific mapping applies to = i2c_baudrate, and the other i2c baudrate parameters. . . . Name: i2c1 Info: Change i2c1 pin usage. Not all pin combinations are usable on = all platforms - platforms other then Compute Modules can only use = this to disable transaction combining. Load: dtoverlay=3Di2c1,=3D Params: pins_2_3 Use pins 2 and 3 (default) pins_44_45 Use pins 44 and 45 combine Allow transactions to be combined = (default "yes") (My Note: See the "platforms other then Compute Modules . . ." material above. So no pin_func param to explicitly control.) . . . (The below also mentions pins 2 and 3) Name: i2c3 Info: Enable the i2c3 bus. BCM2711 only. Load: dtoverlay=3Di2c3, Params: pins_2_3 Use GPIOs 2 and 3 pins_4_5 Use GPIOs 4 and 5 (default) baudrate Set the baudrate for the interface = (default "100000") Using the overlay via dtoverlay=3Di2c1 in config.txt produced: . . . MESS:00:00:07.045819:0: dtdebug: Opened overlay file = 'overlays/i2c1.dtbo' MESS:00:00:07.051921:0: brfs: File read: /mfs/sd/overlays/i2c1.dtbo MESS:00:00:07.077833:0: Loaded overlay 'i2c1' MESS:00:00:07.081221:0: dtdebug: fragment 2 disabled MESS:00:00:07.083905:0: dtdebug: fragment 3 disabled MESS:00:00:07.107446:0: dtdebug: = merge_fragment(/soc/i2c@7e804000,/fragment@0/__overlay__) MESS:00:00:07.112689:0: dtdebug: +prop(status) MESS:00:00:07.118171:0: dtdebug: +prop(pinctrl-names) MESS:00:00:07.123079:0: dtdebug: +prop(pinctrl-0) MESS:00:00:07.127697:0: dtdebug: merge_fragment() end MESS:00:00:07.146539:0: dtdebug: = merge_fragment(/soc/gpio@7e200000/i2c1,/fragment@1/__overlay__) MESS:00:00:07.152260:0: dtdebug: +prop(brcm,pins) MESS:00:00:07.158152:0: dtdebug: +prop(brcm,function) MESS:00:00:07.163211:0: dtdebug: merge_fragment() end MESS:00:00:07.166676:0: dtdebug: fragment 2 disabled MESS:00:00:07.171375:0: dtdebug: fragment 3 disabled . . . but alt0 was not set up and nothing in the fdt print looked different (other than the seeds). (I've no clue what the "fragment ? disabled" messages from the RPi firmware are about.) I see no evidence that i2c1.dtbo (no params) does anything that the FreeBSD kernel could notice as different. Thus it is not obvious to me that the kernel is doing anything wrong here. But I've not decompiled i2c1.dtbo either, so I've yet to have evidence of what its effect should be relative to alt0 status for gpio2 and 3. NOTE: I use all 3 of: enable_uart=3D1 uart_2ndstage=3D1 dtdebug=3D1 in config.txt to get more output on the serial console for the firmware stages. I also use: BOOT_UART=3D1 in the eeprom boot loader configuration (and in bootcode.bin on RPI*'s that use it). =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)