Date: Sat, 1 May 2021 19:58:41 -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: <8CBBAE44-E736-4DEF-BA60-4D5068D25C15@yahoo.com> In-Reply-To: <D205D9F9-8A4D-433B-9AAA-8904850AF787@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>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-May-1, at 08:31, Mark Millard <marklmi at yahoo.com> wrote: > 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.) [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<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> . . . =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,<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") (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,<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") 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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8CBBAE44-E736-4DEF-BA60-4D5068D25C15>