Re: I2C/IIC working on RPI4 8GB?
Mark Millard via freebsd-arm <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.arm |
|---|---|
| Message-ID | <[email protected]> |
>
>
> On 2021-May-1, at 19:58, Mark Millard <marklmi at yahoo.com> wrote:
>
> 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:
>>
>>> On 30 Apr 2021, at 15:22, Klaus Küchemann <maciphone2 at googlemail.com> wrote:
>>>>
>>>>
>>>> yet another useful document(at least that's what I hope to fix your usecase) :
>>>>
>>>> https://www.raspberrypi.org/documentation/configuration/config-txt/gpio.md
>>>
>>> BINGO!!
>>>
>>> I added
>>>
>>> gpio=2,3=a0
>>>
>>> to my config.txt file and after a reboot,
>>>
>>> # i2c -f /dev/iic0 -s worked!
>>
>>
>> Cool.
>>
>> 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).
>>
>> (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 = 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=i2c0
> MESS:00:00:06.179873:0: dtdebug: /__symbols__:i2c_vc=i2c0
> MESS:00:00:06.185545:0: dtdebug: /__overrides__:i2c_vc=i2c0
> MESS:00:00:06.194913:0: dtdebug: /__overrides__:i2c_vc_baudrate=i2c0_baudrate
> MESS:00:00:06.200209:0: dtdebug: /aliases:i2c=i2c1
> MESS:00:00:06.208333:0: dtdebug: /__symbols__:i2c=i2c1
> MESS:00:00:06.213770:0: dtdebug: /__overrides__:i2c=i2c1
> MESS:00:00:06.217250:0: dtdebug: /aliases:i2c_arm=i2c1
> MESS:00:00:06.225726:0: dtdebug: /__symbols__:i2c_arm=i2c1
> MESS:00:00:06.231504:0: dtdebug: /__overrides__:i2c_arm=i2c1
> MESS:00:00:06.241007:0: dtdebug: /__overrides__:i2c_baudrate=i2c1_baudrate
> MESS:00:00:06.251752:0: dtdebug: /__overrides__:i2c_arm_baudrate=i2c1_baudrate
> . . .
> MESS:00:00:06.308655:0: dtparam: i2c_arm=on
> 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_pins)
> 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 = "/soc/i2c@7e804000";
> . . .
> dpi_gpio0 {
> brcm,pins = <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 = <0x00000006>;
> phandle = <0x00000048>;
> };
> . . . (I think the below i2c1_gpio2 indicates alt0)
> i2c1_gpio2 {
> brcm,pins = <0x00000002 0x00000003>;
> brcm,function = <0x00000004>;
> phandle = <0x00000052>;
> };
> . . .
> i2c3_gpio2 {
> phandle = <0x0000006d>;
> pin-sda {
> function = "alt5";
> pins = "gpio2";
> bias-pull-up;
> };
> pin-scl {
> function = "alt5";
> pins = "gpio3";
> bias-disable;
> };
> };
> . . .
> spi3_gpio0 {
> phandle = <0x00000088>;
> pins-spi {
> pins = "gpio0", "gpio1", "gpio2", "gpio3";
> function = "alt3";
> };
> };
> . . .
> uart2_ctsrts_gpio2 {
> phandle = <0x0000008d>;
> pin-cts {
> pins = "gpio2";
> function = "alt4";
> bias-pull-up;
> };
> pin-rts {
> pins = "gpio3";
> function = "alt4";
> bias-disable;
> };
> };
> . . .
> dpi_18bit_gpio0 {
> brcm,pins = <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 = <0x00000006>;
> phandle = <0x00000096>;
> };
> dpi_18bit_gpio2 {
> brcm,pins = <0x00000002 0x00000003 0x00000004 0x00000005 0x00000006 0x00000007 0x00000008 0x00000009 0x0000000a 0x0000000b 0x0000000c 0x0000000d 0x0000000e 0x0000000f 0
> x00000010 0x00000011 0x00000012 0x00000013 0x00000014 0x00000015>;
> brcm,function = <0x00000006>;
> phandle = <0x00000097>;
> };
> . . .
> spi3_pins {
> brcm,pins = <0x00000001 0x00000002 0x00000003>;
> brcm,function = <0x00000007>;
> phandle = <0x00000098>;
> };
> . . . (I think the below i2c1 indicates alt0)
> i2c1 {
> brcm,pins = <0x00000002 0x00000003>;
> brcm,function = <0x00000004>;
> brcm,pull = <0x00000002>;
> phandle = <0x00000017>;
> };
> . . .
> i2c1 = [00 00 00 35 73 74 61 74 75 73 00];
> . . .
> i2c1_gpio2 = "/soc/gpio@7e200000/i2c1_gpio2";
> . . .
> i2c3_gpio2 = "/soc/gpio@7e200000/i2c3_gpio2";
> . . .
> uart2_ctsrts_gpio2 = "/soc/gpio@7e200000/uart2_ctsrts_gpio2";
> . . .
> dpi_18bit_gpio2 = "/soc/gpio@7e200000/dpi_18bit_gpio2";
> . . .
> i2c1_pins = "/soc/gpio@7e200000/i2c1";
> . . .
>
> There is sort of an overall alt0 --that omits mention
> of gpio2 and 3:
>
> . . .
> alt0 {
> brcm,pins = <0x00000004 0x00000005 0x00000007 0x00000008 0x00000009 0x0000000a 0x0000000b>;
> brcm,function = <0x00000004>;
> phandle = <0x00000095>;
> };
> . . .
> alt0 = "/soc/gpio@7e200000/alt0";
> . . .
>
>
> The same was true with gpio=2,3=a0 in the config.txt .
> The only diff reported for the fdt print output was:
>
> chosen {
> - kaslr-seed = <0x3bab60e6 0x2352e756>;
> + kaslr-seed = <0x2adcd524 0x37345f4c>;
> rpi-boardrev-ext = <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>
> . . .
>
> From 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=i2c1,<param>=<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=i2c3,<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=i2c1 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.
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.
>
>
>
> NOTE: I use all 3 of:
>
> enable_uart=1
> uart_2ndstage=1
> dtdebug=1
>
> in config.txt to get more output on the serial
> console for the firmware stages. I also use:
>
> BOOT_UART=1
>
> in the eeprom boot loader configuration (and
> in bootcode.bin on RPI*'s that use it).
>
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[email protected]"