Date: Sat, 1 May 2021 20:14:23 -0700 From: Mark Millard <marklmi@yahoo.com> To: Mark Murray <markm@freebsd.org> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: I2C/IIC working on RPI4 8GB? Message-ID: <38E50925-7010-48F3-94A0-DD195DC442F4@yahoo.com> In-Reply-To: <8CBBAE44-E736-4DEF-BA60-4D5068D25C15@yahoo.com> References: <1C2DD11C-B1F6-4C2A-9AB0-5F1553520FF5@FreeBSD.org> <20210426161138.a8f44b6e1134f73a411be57d@bidouilliste.com> <CF4C4332-BB2F-47E9-B879-8EEA0E53E848@FreeBSD.org> <C4828BF2-E8B7-45D1-B0F8-5E72AF84D565@yahoo.com> <47A634E3-4938-4AFC-9341-E480CEBF67FB@FreeBSD.org> <20210428101945.67417ef8eba251dcbcb38078@bidouilliste.com> <ED9ABBBE-9B5A-4B51-806C-F91AABE39731@FreeBSD.org> <486E3EA3-EBAE-492E-B12E-E72E3E3E7B6A@FreeBSD.org> <A10EA46D-6FE5-4FCD-895C-5A08A974D6DB@yahoo.com> <E9098242-5ED4-401B-9D46-E11A214A0E2F@FreeBSD.org> <F38325DB-DC0E-44F8-A256-A5D6A23925D0@googlemail.com> <501CB1C0-73D4-4BEF-A1E6-1F13C02EFA42@FreeBSD.org> <D205D9F9-8A4D-433B-9AAA-8904850AF787@yahoo.com> <8CBBAE44-E736-4DEF-BA60-4D5068D25C15@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>=20 >=20 > On 2021-May-1, at 19:58, Mark Millard <marklmi at yahoo.com> wrote: >=20 > On 2021-May-1, at 08:31, Mark Millard <marklmi at yahoo.com> wrote: >=20 >> On 2021-May-1, at 04:48, Mark Murray <markm at freebsd.org> wrote: >>=20 >>> On 30 Apr 2021, at 15:22, Klaus K=C3=BCchemann <maciphone2 at = googlemail.com> 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.) >=20 > [I was given a code hint that I've not investigated yet.] >=20 > But going in a different direction, based on my default > context on the local FreeBSD RPI4B 8 GiByte: >=20 > In BCM2835-ARM-Peripherals.pdf I see that the bits are > in: >=20 > Address Field Name Description Size Read/ Write >=20 > 0x 7E20 0000 GPFSEL0 GPIO Function Select 0 32 R/W >=20 >=20 > Bit fields: >=20 > 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 >=20 > for the 3 bit sequence: >=20 > 100 =3D GPIO Pin ? takes alternate function 0 >=20 > (so 0x4 shifted over) >=20 > With dtdebug enabled in config.txt for the RPi firmware > I see: >=20 > 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 >=20 >=20 > Then, based on using: >=20 > Using DTB provided by EFI at 0x7ef0000. >=20 > stopping in U-Boot and doing: >=20 > U-Boot> fdt addr 0x7ef0000 > U-Boot> fdt print >=20 > it provides dtb material from after any dynamic > substitutions, not just what is in the .dtb > file. >=20 > Looking I see various alternatives, some of which > look to have the 0x4 to be shifted over for gpio2 > and for gpio33: >=20 > . . . > 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"; > . . . >=20 > There is sort of an overall alt0 --that omits mention > of gpio2 and 3: >=20 > . . . > alt0 { > brcm,pins =3D <0x00000004 0x00000005 = 0x00000007 0x00000008 0x00000009 0x0000000a 0x0000000b>; > brcm,function =3D <0x00000004>; > phandle =3D <0x00000095>; > }; > . . . > alt0 =3D "/soc/gpio@7e200000/alt0"; > . . . >=20 >=20 > The same was true with gpio=3D2,3=3Da0 in the config.txt . > The only diff reported for the fdt print output was: >=20 > chosen { > - kaslr-seed =3D <0x3bab60e6 0x2352e756>; > + kaslr-seed =3D <0x2adcd524 0x37345f4c>; > rpi-boardrev-ext =3D <0x00000000>; >=20 > But I have confirmed a difference via how pins 2 and > 3 show up via: >=20 > # gpioctl -f /dev/gpioc0 -l -v > pin 00: 1 pin 0<IN>, = caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB> > pin 01: 1 pin 1<IN>, = caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB> > pin 02: 1 pin 2<>, = caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB> > pin 03: 1 pin 3<>, = caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB> > pin 04: 1 pin 4<IN>, = caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB> > pin 05: 1 pin 5<IN>, = caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB> > . . . >=20 > =46rom the all the above I gather that the right i2c*.dtbo is from: >=20 > /usr/local/share/rpi-firmware/overlays/i2c1.dtbo >=20 > (just based on the "i2c1" part of the naming). >=20 > But the Readme.md for overlays/ reports: >=20 > 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,<param>=3D<val> > 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") >=20 > (My Note: See the "platforms other then Compute Modules . . ." > material above. So no pin_func param to explicitly control.) >=20 > . . . (The below also mentions pins 2 and 3) > Name: i2c3 > Info: Enable the i2c3 bus. BCM2711 only. > Load: dtoverlay=3Di2c3,<param> > 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") >=20 > Using the overlay via dtoverlay=3Di2c1 in config.txt produced: >=20 > . . . > 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 > . . . >=20 > 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.) >=20 >=20 > 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. Bad wording: I meant relative to the .dtbo . The kernel mishandling the overall .dtb that it is given could still be the case. > 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. >=20 >=20 >=20 > NOTE: I use all 3 of: >=20 > enable_uart=3D1 > uart_2ndstage=3D1 > dtdebug=3D1 >=20 > in config.txt to get more output on the serial > console for the firmware stages. I also use: >=20 > BOOT_UART=3D1 >=20 > in the eeprom boot loader configuration (and > in bootcode.bin on RPI*'s that use it). >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?38E50925-7010-48F3-94A0-DD195DC442F4>