I2C/IIC working on RPI4 8GB?

[Mark Murray]

Hi All,

Does anyone here have IIC/I2C working on a CURRENT (I'm running latest) FreeBSD?

I've never seen it work; Last time I had working IIC was on an RPI3.

There is a /dev/iic0, and I have a known working RTC on it, but the scan just times out:

[***@grasshopper ~]# i2c -s
Hardware may not support START/STOP scanning; trying less-reliable read method.
<TIMEOUT>
Scanning I2C devices on /dev/iic0: <none found>


I suspect something not-quite-right in DTS land, but I lack the knowledge to investigate. I've done some random stumbling around in the dark with overlays and the like, but I've either seen the above error, or a total lack of /dev/iic0.

Thanks!

M
--
Mark R V Murray

[Daniel Braniss]

Post by Mark Murray
Hi All,
Does anyone here have IIC/I2C working on a CURRENT (I'm running latest) FreeBSD?
I've never seen it work; Last time I had working IIC was on an RPI3.
Hardware may not support START/STOP scanning; trying less-reliable read method.
<TIMEOUT>
Scanning I2C devices on /dev/iic0: <none found>
I suspect something not-quite-right in DTS land, but I lack the knowledge to investigate. I've done some random stumbling around in the dark with overlays and the like, but I've either seen the above error, or a total lack of /dev/iic0.
Thanks!
M
--
Mark R V Murray

Q1: do you see /dev/iic?
Q2: i2c -s shows anything?

fianlly, you can try my patch, it works for me, but I understand it’s a five kilo hammer :-)

diff --git a/sys/dev/iicbus/twsi/twsi.c b/sys/dev/iicbus/twsi/twsi.c
index a606c2aef..8ede62073 100644
--- a/sys/dev/iicbus/twsi/twsi.c
+++ b/sys/dev/iicbus/twsi/twsi.c
@@ -86,6 +86,8 @@ __FBSDID("$FreeBSD$");
#define TWSI_DEBUG
#undef TWSI_DEBUG

+#define debug_(dev, fmt, args...) device_printf(dev, "%s: " fmt, __func__, ##args)
+
#ifdef TWSI_DEBUG
#define debugf(dev, fmt, args...) device_printf(dev, "%s: " fmt, __func__, ##args)
#else
@@ -103,6 +105,7 @@ TWSI_READ(struct twsi_softc *sc, bus_size_t off)
{
uint32_t val;

+ DELAY(1000); // danny: needed
val = bus_read_4(sc->res[0], off);
debugf(sc->dev, "read %x from %lx\n", val, off);
return (val);
@@ -165,15 +168,14 @@ twsi_clear_iflg(struct twsi_softc *sc)
static int
twsi_poll_ctrl(struct twsi_softc *sc, int timeout, uint32_t mask)
{
-
timeout /= 10;
- debugf(sc->dev, "Waiting for ctrl reg to match mask %x\n", mask);
+ debug_(sc->dev, "Waiting for ctrl reg to match mask %x timeout=%d\n", mask, timeout);
while (!(TWSI_READ(sc, sc->reg_control) & mask)) {
- DELAY(10);
+ // DELAY(10);
if (--timeout < 0)
return (timeout);
}
- debugf(sc->dev, "done\n");
+ debug_(sc->dev, "done\n");
return (0);
}

@@ -212,7 +214,7 @@ twsi_locked_start(device_t dev, struct twsi_softc *sc, int32_t mask,
DELAY(1000);

if (twsi_poll_ctrl(sc, timeout, TWSI_CONTROL_IFLG)) {
- debugf(dev, "timeout sending %sSTART condition\n",
+ debug_(dev, "timeout sending %sSTART condition\n",
mask == TWSI_STATUS_START ? "" : "repeated ");
return (IIC_ETIMEOUT);
}
@@ -221,7 +223,7 @@ twsi_locked_start(device_t dev, struct twsi_softc *sc, int32_t mask,
debugf(dev, "status=%x\n", status);

if (status != mask) {
- debugf(dev, "wrong status (%02x) after sending %sSTART condition\n",
+ debug_(dev, "wrong status (%02x) after sending %sSTART condition\n",
status, mask == TWSI_STATUS_START ? "" : "repeated ");
return (IIC_ESTATUS);
}
@@ -231,7 +233,7 @@ twsi_locked_start(device_t dev, struct twsi_softc *sc, int32_t mask,
DELAY(1000);

if (twsi_poll_ctrl(sc, timeout, TWSI_CONTROL_IFLG)) {
- debugf(dev, "timeout sending slave address (timeout=%d)\n", timeout);
+ debug_(dev, "timeout sending slave address (timeout=%d)\n", timeout);
return (IIC_ETIMEOUT);
}

@@ -239,7 +241,7 @@ twsi_locked_start(device_t dev, struct twsi_softc *sc, int32_t mask,
status = TWSI_READ(sc, sc->reg_status);
if (status != (read_access ?
TWSI_STATUS_ADDR_R_ACK : TWSI_STATUS_ADDR_W_ACK)) {
- debugf(dev, "no ACK (status: %02x) after sending slave address\n",
+ debug_(dev, "no ACK (status: %02x) after sending slave address\n",
status);
return (IIC_ENOACK);
}
@@ -405,7 +407,8 @@ twsi_read(device_t dev, char *buf, int len, int *read, int last, int delay)
int last_byte, rv;

sc = device_get_softc(dev);
-
+ debug_(dev, "twsi_read: len=%d delay=%d", len, delay); // danny
+
mtx_lock(&sc->mutex);
*read = 0;
while (*read < len) {
@@ -423,7 +426,7 @@ twsi_read(device_t dev, char *buf, int len, int *read, int last, int delay)
DELAY(1000);

if (twsi_poll_ctrl(sc, delay, TWSI_CONTROL_IFLG)) {
- debugf(dev, "timeout reading data (delay=%d)\n", delay);
+ debug_(dev, "timeout reading data (delay=%d)\n", delay);
rv = IIC_ETIMEOUT;
goto out;
}
@@ -431,7 +434,7 @@ twsi_read(device_t dev, char *buf, int len, int *read, int last, int delay)
status = TWSI_READ(sc, sc->reg_status);
if (status != (last_byte ?
TWSI_STATUS_DATA_RD_NOACK : TWSI_STATUS_DATA_RD_ACK)) {
- debugf(dev, "wrong status (%02x) while reading\n", status);
+ debug_(dev, "wrong status (%02x) while reading\n", status);
rv = IIC_ESTATUS;
goto out;
}
@@ -462,14 +465,14 @@ twsi_write(device_t dev, const char *buf, int len, int *sent, int timeout)
twsi_clear_iflg(sc);
DELAY(1000);
if (twsi_poll_ctrl(sc, timeout, TWSI_CONTROL_IFLG)) {
- debugf(dev, "timeout writing data (timeout=%d)\n", timeout);
+ debug_(dev, "timeout writing data (timeout=%d)\n", timeout);
rv = IIC_ETIMEOUT;
goto out;
}

status = TWSI_READ(sc, sc->reg_status);
if (status != TWSI_STATUS_DATA_WR_ACK) {
- debugf(dev, "wrong status (%02x) while writing\n", status);
+ debug_(dev, "wrong status (%02x) while writing\n", status);
rv = IIC_ESTATUS;
goto out;
}
@@ -496,8 +499,12 @@ twsi_transfer(device_t dev, struct iic_msg *msgs, uint32_t nmsgs)
sc->control_val = TWSI_CONTROL_TWSIEN |
TWSI_CONTROL_INTEN | TWSI_CONTROL_ACK;
TWSI_WRITE(sc, sc->reg_control, sc->control_val);
- debugf(dev, "transmitting %d messages\n", nmsgs);
- debugf(sc->dev, "status=%x\n", TWSI_READ(sc, sc->reg_status));
+#if 0
+ debug_(dev, "transmitting %d messages\n", nmsgs);
+ debug_(sc->dev, "status=%x\n", TWSI_READ(sc, sc->reg_status));
+#else
+ DELAY(8000);
+#endif
sc->nmsgs = nmsgs;
sc->msgs = msgs;
sc->msg_idx = 0;
@@ -519,15 +526,24 @@ twsi_transfer(device_t dev, struct iic_msg *msgs, uint32_t nmsgs)
debugf(sc->dev, "pause finish\n");

if (sc->error) {
- debugf(sc->dev, "Error, aborting (%d)\n", sc->error);
+ debug_(sc->dev, "Error, aborting (%d)\n", sc->error);
TWSI_WRITE(sc, sc->reg_control, 0);
}

/* Disable module and interrupts */
- debugf(sc->dev, "status=%x\n", TWSI_READ(sc, sc->reg_status));
+#if 0
+ debug_(sc->dev, "status=%x\n", TWSI_READ(sc, sc->reg_status)); //
TWSI_WRITE(sc, sc->reg_control, 0);
- debugf(sc->dev, "status=%x\n", TWSI_READ(sc, sc->reg_status));
-
+ debugf(sc->dev, "status=%x\n", TWSI_READ(sc, sc->reg_status)); //
+ debugf(sc->dev, "error=%d\n", sc->error); // danny
+#else
+ int status;
+ DELAY(8000); // danny: works!
+ status = TWSI_READ(sc, sc->reg_status);
+ TWSI_WRITE(sc, sc->reg_control, 0);
+ status = TWSI_READ(sc, sc->reg_status);
+ //debug_(sc->dev, "status=%x\n", TWSI_READ(sc, sc->reg_status));
+#endif
return (sc->error);
}

@@ -581,7 +597,7 @@ twsi_intr(void *arg)

case TWSI_STATUS_ADDR_W_NACK:
case TWSI_STATUS_ADDR_R_NACK:
- debugf(sc->dev, "No ack received after transmitting the address\n");
+ debug_(sc->dev, "No ack received after transmitting the address\n");
sc->transfer = 0;
sc->error = IIC_ENOACK;
sc->control_val = 0;
@@ -662,7 +678,7 @@ twsi_intr(void *arg)
break;

default:
- debugf(sc->dev, "status=%x hot handled\n", status);
+ debug_(sc->dev, "status=%x hot handled\n", status);
sc->transfer = 0;
sc->error = IIC_EBUSERR;
sc->control_val = 0;

[Emmanuel Vadot]

On Sun, 25 Apr 2021 18:41:31 +0300

Post by Daniel Braniss

Post by Mark Murray
Hi All,
Does anyone here have IIC/I2C working on a CURRENT (I'm running latest) FreeBSD?
I've never seen it work; Last time I had working IIC was on an RPI3.
Hardware may not support START/STOP scanning; trying less-reliable read method.
<TIMEOUT>
Scanning I2C devices on /dev/iic0: <none found>
I suspect something not-quite-right in DTS land, but I lack the knowledge to investigate. I've done some random stumbling around in the dark with overlays and the like, but I've either seen the above error, or a total lack of /dev/iic0.
Thanks!
M
--
Mark R V Murray

Q1: do you see /dev/iic?
Q2: i2c -s shows anything?
fianlly, you can try my patch, it works for me, but I understand it?s a five kilo hammer :-)

RPI doesn't uses twsi so that will not change a thing.

Post by Daniel Braniss
diff --git a/sys/dev/iicbus/twsi/twsi.c b/sys/dev/iicbus/twsi/twsi.c
index a606c2aef..8ede62073 100644
--- a/sys/dev/iicbus/twsi/twsi.c
+++ b/sys/dev/iicbus/twsi/twsi.c
@@ -86,6 +86,8 @@ __FBSDID("$FreeBSD$");
#define TWSI_DEBUG
#undef TWSI_DEBUG
+#define debug_(dev, fmt, args...) device_printf(dev, "%s: " fmt, __func__, ##args)
+
#ifdef TWSI_DEBUG
#define debugf(dev, fmt, args...) device_printf(dev, "%s: " fmt, __func__, ##args)
#else
@@ -103,6 +105,7 @@ TWSI_READ(struct twsi_softc *sc, bus_size_t off)
{
uint32_t val;
+ DELAY(1000); // danny: needed
val = bus_read_4(sc->res[0], off);
debugf(sc->dev, "read %x from %lx\n", val, off);
return (val);
@@ -165,15 +168,14 @@ twsi_clear_iflg(struct twsi_softc *sc)
static int
twsi_poll_ctrl(struct twsi_softc *sc, int timeout, uint32_t mask)
{
-
timeout /= 10;
- debugf(sc->dev, "Waiting for ctrl reg to match mask %x\n", mask);
+ debug_(sc->dev, "Waiting for ctrl reg to match mask %x timeout=%d\n", mask, timeout);
while (!(TWSI_READ(sc, sc->reg_control) & mask)) {
- DELAY(10);
+ // DELAY(10);
if (--timeout < 0)
return (timeout);
}
- debugf(sc->dev, "done\n");
+ debug_(sc->dev, "done\n");
return (0);
}
@@ -212,7 +214,7 @@ twsi_locked_start(device_t dev, struct twsi_softc *sc, int32_t mask,
DELAY(1000);
if (twsi_poll_ctrl(sc, timeout, TWSI_CONTROL_IFLG)) {
- debugf(dev, "timeout sending %sSTART condition\n",
+ debug_(dev, "timeout sending %sSTART condition\n",
mask == TWSI_STATUS_START ? "" : "repeated ");
return (IIC_ETIMEOUT);
}
@@ -221,7 +223,7 @@ twsi_locked_start(device_t dev, struct twsi_softc *sc, int32_t mask,
debugf(dev, "status=%x\n", status);
if (status != mask) {
- debugf(dev, "wrong status (%02x) after sending %sSTART condition\n",
+ debug_(dev, "wrong status (%02x) after sending %sSTART condition\n",
status, mask == TWSI_STATUS_START ? "" : "repeated ");
return (IIC_ESTATUS);
}
@@ -231,7 +233,7 @@ twsi_locked_start(device_t dev, struct twsi_softc *sc, int32_t mask,
DELAY(1000);
if (twsi_poll_ctrl(sc, timeout, TWSI_CONTROL_IFLG)) {
- debugf(dev, "timeout sending slave address (timeout=%d)\n", timeout);
+ debug_(dev, "timeout sending slave address (timeout=%d)\n", timeout);
return (IIC_ETIMEOUT);
}
@@ -239,7 +241,7 @@ twsi_locked_start(device_t dev, struct twsi_softc *sc, int32_t mask,
status = TWSI_READ(sc, sc->reg_status);
if (status != (read_access ?
TWSI_STATUS_ADDR_R_ACK : TWSI_STATUS_ADDR_W_ACK)) {
- debugf(dev, "no ACK (status: %02x) after sending slave address\n",
+ debug_(dev, "no ACK (status: %02x) after sending slave address\n",
status);
return (IIC_ENOACK);
}
@@ -405,7 +407,8 @@ twsi_read(device_t dev, char *buf, int len, int *read, int last, int delay)
int last_byte, rv;
sc = device_get_softc(dev);
-
+ debug_(dev, "twsi_read: len=%d delay=%d", len, delay); // danny
+
mtx_lock(&sc->mutex);
*read = 0;
while (*read < len) {
@@ -423,7 +426,7 @@ twsi_read(device_t dev, char *buf, int len, int *read, int last, int delay)
DELAY(1000);
if (twsi_poll_ctrl(sc, delay, TWSI_CONTROL_IFLG)) {
- debugf(dev, "timeout reading data (delay=%d)\n", delay);
+ debug_(dev, "timeout reading data (delay=%d)\n", delay);
rv = IIC_ETIMEOUT;
goto out;
}
@@ -431,7 +434,7 @@ twsi_read(device_t dev, char *buf, int len, int *read, int last, int delay)
status = TWSI_READ(sc, sc->reg_status);
if (status != (last_byte ?
TWSI_STATUS_DATA_RD_NOACK : TWSI_STATUS_DATA_RD_ACK)) {
- debugf(dev, "wrong status (%02x) while reading\n", status);
+ debug_(dev, "wrong status (%02x) while reading\n", status);
rv = IIC_ESTATUS;
goto out;
}
@@ -462,14 +465,14 @@ twsi_write(device_t dev, const char *buf, int len, int *sent, int timeout)
twsi_clear_iflg(sc);
DELAY(1000);
if (twsi_poll_ctrl(sc, timeout, TWSI_CONTROL_IFLG)) {
- debugf(dev, "timeout writing data (timeout=%d)\n", timeout);
+ debug_(dev, "timeout writing data (timeout=%d)\n", timeout);
rv = IIC_ETIMEOUT;
goto out;
}
status = TWSI_READ(sc, sc->reg_status);
if (status != TWSI_STATUS_DATA_WR_ACK) {
- debugf(dev, "wrong status (%02x) while writing\n", status);
+ debug_(dev, "wrong status (%02x) while writing\n", status);
rv = IIC_ESTATUS;
goto out;
}
@@ -496,8 +499,12 @@ twsi_transfer(device_t dev, struct iic_msg *msgs, uint32_t nmsgs)
sc->control_val = TWSI_CONTROL_TWSIEN |
TWSI_CONTROL_INTEN | TWSI_CONTROL_ACK;
TWSI_WRITE(sc, sc->reg_control, sc->control_val);
- debugf(dev, "transmitting %d messages\n", nmsgs);
- debugf(sc->dev, "status=%x\n", TWSI_READ(sc, sc->reg_status));
+#if 0
+ debug_(dev, "transmitting %d messages\n", nmsgs);
+ debug_(sc->dev, "status=%x\n", TWSI_READ(sc, sc->reg_status));
+#else
+ DELAY(8000);
+#endif
sc->nmsgs = nmsgs;
sc->msgs = msgs;
sc->msg_idx = 0;
@@ -519,15 +526,24 @@ twsi_transfer(device_t dev, struct iic_msg *msgs, uint32_t nmsgs)
debugf(sc->dev, "pause finish\n");
if (sc->error) {
- debugf(sc->dev, "Error, aborting (%d)\n", sc->error);
+ debug_(sc->dev, "Error, aborting (%d)\n", sc->error);
TWSI_WRITE(sc, sc->reg_control, 0);
}
/* Disable module and interrupts */
- debugf(sc->dev, "status=%x\n", TWSI_READ(sc, sc->reg_status));
+#if 0
+ debug_(sc->dev, "status=%x\n", TWSI_READ(sc, sc->reg_status)); //
TWSI_WRITE(sc, sc->reg_control, 0);
- debugf(sc->dev, "status=%x\n", TWSI_READ(sc, sc->reg_status));
-
+ debugf(sc->dev, "status=%x\n", TWSI_READ(sc, sc->reg_status)); //
+ debugf(sc->dev, "error=%d\n", sc->error); // danny
+#else
+ int status;
+ DELAY(8000); // danny: works!
+ status = TWSI_READ(sc, sc->reg_status);
+ TWSI_WRITE(sc, sc->reg_control, 0);
+ status = TWSI_READ(sc, sc->reg_status);
+ //debug_(sc->dev, "status=%x\n", TWSI_READ(sc, sc->reg_status));
+#endif
return (sc->error);
}
@@ -581,7 +597,7 @@ twsi_intr(void *arg)
- debugf(sc->dev, "No ack received after transmitting the address\n");
+ debug_(sc->dev, "No ack received after transmitting the address\n");
sc->transfer = 0;
sc->error = IIC_ENOACK;
sc->control_val = 0;
@@ -662,7 +678,7 @@ twsi_intr(void *arg)
break;
- debugf(sc->dev, "status=%x hot handled\n", status);
+ debug_(sc->dev, "status=%x hot handled\n", status);
sc->transfer = 0;
sc->error = IIC_EBUSERR;
sc->control_val = 0;
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-arm

[Daniel Braniss]

Post by Emmanuel Vadot
On Sun, 25 Apr 2021 18:41:31 +0300

Post by Daniel Braniss

Post by Mark Murray
Hi All,
Does anyone here have IIC/I2C working on a CURRENT (I'm running latest) FreeBSD?
I've never seen it work; Last time I had working IIC was on an RPI3.
Hardware may not support START/STOP scanning; trying less-reliable read method.
<TIMEOUT>
Scanning I2C devices on /dev/iic0: <none found>
I suspect something not-quite-right in DTS land, but I lack the knowledge to investigate. I've done some random stumbling around in the dark with overlays and the like, but I've either seen the above error, or a total lack of /dev/iic0.
Thanks!
M
--
Mark R V Murray

Q1: do you see /dev/iic?
Q2: i2c -s shows anything?
fianlly, you can try my patch, it works for me, but I understand it?s a five kilo hammer :-)

RPI doesn't uses twsi so that will not change a thing.

vey true
should read Subject: before answering!
I guess not all i2c/iic are born equal:-)

danny

[Mark Millard via freebsd-arm]

Post by Emmanuel Vadot
On Sun, 25 Apr 2021 18:41:31 +0300

. . .

RPI doesn't uses twsi so that will not change a thing.

The RPI4B 8GiByte context I have mentions twsi in
the sysctl output:

# sysctl dev.iichb
dev.iichb.0.debug: 0
dev.iichb.0.rise_edge_delay: 48
dev.iichb.0.fall_edge_delay: 48
dev.iichb.0.clock_stretch: 64
dev.iichb.0.frequency: 100000
dev.iichb.0.%parent: simplebus0
dev.iichb.0.%pnpinfo: name=***@7e804000 compat=brcm,bcm2711-i2c
dev.iichb.0.%location:
dev.iichb.0.%driver: iichb
dev.iichb.0.%desc: BCM2708/2835 BSC controller
dev.iichb.%parent: twsi

(Not that I know the implications, if any.)

Post by Emmanuel Vadot

. . .

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

[Hrant Dadivanyan]

Hi Mark,

Exactly the same here for 13.0-RELEASE. I use ds3231 on RPI-B and RPI3,
but it never works on RPI4 8GB (periodically trying from August 2020 as
far as I can remember). Not even when booting from the SD card pulled
out from RPI3 and inserted into RPI4.
Found the following workaround though (config.txt):
#device_tree_overlay=i2c-rtc,ds3231
device_tree_overlay=i2c-rtc-gpio,ds3231,i2c_gpio_scl=2,i2c_gpio_sda=3
Please note pins REVERSE assignment in config.

# dmesg | egrep -i 'ds3231|rtc|i2c|iic|time-of-day'
iichb0: <BCM2708/2835 BSC controller> mem 0x7e804000-0x7e804fff irq 26
on simplebus0
iicbus0: <OFW I2C bus> on iichb0
iic0: <I2C generic I/O> on iicbus0
Warning: no time-of-day clock registered, system time will not be set
accurately
gpioiic0: <GPIO I2C> on ofwbus0
gpioiic0: SCL pin: gpiobus0:3, SDA pin: gpiobus0:2
iicbb0: <I2C bit-banging driver> on gpioiic0
iicbus1: <OFW I2C bus> on iicbb0 master-only
iic1: <I2C generic I/O> on iicbus1
ds32310: <Maxim DS3231 RTC> at addr 0xd0 on iicbus1
ds32310: registered as a time-of-day clock, resolution 1.000000s
#
Please note pins CORRECT assignment in the dmesg.

Thank you,
Hrant

Post by Mark Murray
Hi All,
Does anyone here have IIC/I2C working on a CURRENT (I'm running latest) FreeBSD?
I've never seen it work; Last time I had working IIC was on an RPI3.
Hardware may not support START/STOP scanning; trying less-reliable read method.
<TIMEOUT>
Scanning I2C devices on /dev/iic0: <none found>
I suspect something not-quite-right in DTS land, but I lack the knowledge to investigate. I've done some random stumbling around in the dark with overlays and the like, but I've either seen the above error, or a total

lack of /dev/iic0.

Post by Mark Murray
Thanks!
M
--
Mark R V Murray

[Emmanuel Vadot]

On Sun, 25 Apr 2021 13:32:00 +0100

Post by Mark Murray
Hi All,
Does anyone here have IIC/I2C working on a CURRENT (I'm running latest) FreeBSD?
I've never seen it work; Last time I had working IIC was on an RPI3.
Hardware may not support START/STOP scanning; trying less-reliable read method.
<TIMEOUT>
Scanning I2C devices on /dev/iic0: <none found>
I suspect something not-quite-right in DTS land, but I lack the knowledge to investigate. I've done some random stumbling around in the dark with overlays and the like, but I've either seen the above error, or a total lack of /dev/iic0.
Thanks!
M
--
Mark R V Murray

I2C is disabled by default.
You need to copy i2c0.dtbo (or i2c1<X> I don't know which one maps to
the pins you want to use) in the ESP partition and add "i2c<X>" to the
dtoverlay line in config.txt

[Mark Murray]

Post by Emmanuel Vadot
On Sun, 25 Apr 2021 13:32:00 +0100

Post by Mark Murray
Hi All,
Does anyone here have IIC/I2C working on a CURRENT (I'm running latest) FreeBSD?
I've never seen it work; Last time I had working IIC was on an RPI3.
Hardware may not support START/STOP scanning; trying less-reliable read method.
<TIMEOUT>
Scanning I2C devices on /dev/iic0: <none found>
I suspect something not-quite-right in DTS land, but I lack the knowledge to investigate. I've done some random stumbling around in the dark with overlays and the like, but I've either seen the above error, or a total lack of /dev/iic0.
Thanks!
M
--
Mark R V Murray

I2C is disabled by default.
You need to copy i2c0.dtbo (or i2c1<X> I don't know which one maps to
the pins you want to use) in the ESP partition and add "i2c<X>" to the
dtoverlay line in config.txt

I want to use the i2c on the "regular" pins, GPIO2 and GPIO3, AKA physical pins 3 and 5.

I looked at all the i2c[0-6].dtbo overlays in /usr/ports/sysutils/rpi-firmware. Only 1 had "pins = <2, 3>", so I used that one. I presume the 2,3 refers to GPIO pin numbers, not physical pin numbers?

Same result as before - long timeout, no I2C.

M
--
Mark R V Murray

[Emmanuel Vadot]

On Tue, 27 Apr 2021 08:52:39 +0100

Post by Mark Murray

Post by Emmanuel Vadot
On Sun, 25 Apr 2021 13:32:00 +0100

Post by Mark Murray
Hi All,
Does anyone here have IIC/I2C working on a CURRENT (I'm running latest) FreeBSD?
I've never seen it work; Last time I had working IIC was on an RPI3.
Hardware may not support START/STOP scanning; trying less-reliable read method.
<TIMEOUT>
Scanning I2C devices on /dev/iic0: <none found>
I suspect something not-quite-right in DTS land, but I lack the knowledge to investigate. I've done some random stumbling around in the dark with overlays and the like, but I've either seen the above error, or a total lack of /dev/iic0.
Thanks!
M
--
Mark R V Murray

I2C is disabled by default.
You need to copy i2c0.dtbo (or i2c1<X> I don't know which one maps to
the pins you want to use) in the ESP partition and add "i2c<X>" to the
dtoverlay line in config.txt

I want to use the i2c on the "regular" pins, GPIO2 and GPIO3, AKA physical pins 3 and 5.
I looked at all the i2c[0-6].dtbo overlays in /usr/ports/sysutils/rpi-firmware. Only 1 had "pins = <2, 3>", so I used that one. I presume the 2,3 refers to GPIO pin numbers, not physical pin numbers?
Same result as before - long timeout, no I2C.
M
--
Mark R V Murray

No they probably refer to the pin number of the SoC (but that might be
the same as the "gpio number" in the pinouts naming of the hat
connector.
I don't have any rpi* here to help you more so hopefully someone else
can/will.

[Mark Millard via freebsd-arm]

Post by Mark Murray

Post by Emmanuel Vadot
On Sun, 25 Apr 2021 13:32:00 +0100

Post by Mark Murray
Hi All,
Does anyone here have IIC/I2C working on a CURRENT (I'm running latest) FreeBSD?
I've never seen it work; Last time I had working IIC was on an RPI3.
Hardware may not support START/STOP scanning; trying less-reliable read method.
<TIMEOUT>
Scanning I2C devices on /dev/iic0: <none found>
I suspect something not-quite-right in DTS land, but I lack the knowledge to investigate. I've done some random stumbling around in the dark with overlays and the like, but I've either seen the above error, or a total lack of /dev/iic0.
Thanks!
M
--
Mark R V Murray

I2C is disabled by default.
You need to copy i2c0.dtbo (or i2c1<X> I don't know which one maps to
the pins you want to use) in the ESP partition and add "i2c<X>" to the
dtoverlay line in config.txt

I want to use the i2c on the "regular" pins, GPIO2 and GPIO3, AKA physical pins 3 and 5.
I looked at all the i2c[0-6].dtbo overlays in /usr/ports/sysutils/rpi-firmware. Only 1 had "pins = <2, 3>", so I used that one. I presume the 2,3 refers to GPIO pin numbers, not physical pin numbers?
Same result as before - long timeout, no I2C.

Did you try the suggestion in:

https://lists.freebsd.org/pipermail/freebsd-arm/2021-April/023687.html

? It suggests that you need to have the config.txt swap
the the pins in order to undo another swap that happens
at some internal stage. The swapped problem was indicated
to be visible in the dmesg reporting and the manual swap
was reported to cause the dmesg reporting to produce the
correct overall result.

(Note: GPIO and I2C are not things I fiddle with. I
just happened to notice that the message indicated had
a specific suggestion to try and you do not seem to
have reported on the result of trying it.)


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

[Mark Murray]

Post by Mark Millard via freebsd-arm
https://lists.freebsd.org/pipermail/freebsd-arm/2021-April/023687.html
? It suggests that you need to have the config.txt swap
the the pins in order to undo another swap that happens
at some internal stage. The swapped problem was indicated
to be visible in the dmesg reporting and the manual swap
was reported to cause the dmesg reporting to produce the
correct overall result.

I took apart the i2c1.dtbo overlay that mentions pins 2, 3, and swapped them, and reassembled the overlay.

Nope. Same problem.

What I have:

[***@grasshopper ~]# dmesg | egrep -i 'ds3231|rtc|i2c|iic|time-of-day'
iichb0: <BCM2708/2835 BSC controller> mem 0x7e804000-0x7e804fff irq 26 on simplebus0
iicbus0: <OFW I2C bus> on iichb0
iic0: <I2C generic I/O> on iicbus0
Warning: no time-of-day clock registered, system time will not be set accurately

[***@grasshopper ~]# ls -al /dev | grep iic
crw------- 1 root wheel 0x44 Apr 28 08:42 iic0

I have found a PDF document "BCM2711 ARM Peripherals", and it says "The BSC controller in the BCM2711 fixes the clock-strectching[sic] bug that was present in BCM283x devices", so I suspect that the device may not be hardware compatible with the RPI3 and earlier.

Time to dig in and hack.

M
--
Mark R V Murray

[Emmanuel Vadot]

On Wed, 28 Apr 2021 09:01:56 +0100

Post by Mark Murray

Post by Mark Millard via freebsd-arm
https://lists.freebsd.org/pipermail/freebsd-arm/2021-April/023687.html
? It suggests that you need to have the config.txt swap
the the pins in order to undo another swap that happens
at some internal stage. The swapped problem was indicated
to be visible in the dmesg reporting and the manual swap
was reported to cause the dmesg reporting to produce the
correct overall result.

I took apart the i2c1.dtbo overlay that mentions pins 2, 3, and swapped them, and reassembled the overlay.

This suggestion is to use i2c over gpio via iicbb, not the i2c
controller in the SoC.

Post by Mark Murray
Nope. Same problem.
iichb0: <BCM2708/2835 BSC controller> mem 0x7e804000-0x7e804fff irq 26 on simplebus0
iicbus0: <OFW I2C bus> on iichb0
iic0: <I2C generic I/O> on iicbus0
Warning: no time-of-day clock registered, system time will not be set accurately
crw------- 1 root wheel 0x44 Apr 28 08:42 iic0
I have found a PDF document "BCM2711 ARM Peripherals", and it says "The BSC controller in the BCM2711 fixes the clock-strectching[sic] bug that was present in BCM283x devices", so I suspect that the device may not be hardware compatible with the RPI3 and earlier.

According to this document is this just to detect that the slave hold
the scl line too long so I don't think that this is the problem here.
If you have a scope or a logic analyzer I suggest you start by using
it to confirm that when you scan with i2c -s you see something.

Post by Mark Murray
Time to dig in and hack.
M
--
Mark R V Murray

[Mark Murray]

Post by Emmanuel Vadot
On Wed, 28 Apr 2021 09:01:56 +0100

Post by Mark Murray
I took apart the i2c1.dtbo overlay that mentions pins 2, 3, and swapped them, and reassembled the overlay.

This suggestion is to use i2c over gpio via iicbb, not the i2c
controller in the SoC.

Er, right :-). I'll consider that approach if I can't get the BSC to work

Post by Emmanuel Vadot
According to this document is this just to detect that the slave hold
the scl line too long so I don't think that this is the problem here.
If you have a scope or a logic analyzer I suggest you start by using
it to confirm that when you scan with i2c -s you see something.

As it turns out, my logic analyser arrived today.

This is a perfect project for it :-)

Thanks!

M
--
Mark R V Murray

[Mark Murray]

Post by Mark Murray

Post by Emmanuel Vadot
According to this document is this just to detect that the slave hold
the scl line too long so I don't think that this is the problem here.
If you have a scope or a logic analyzer I suggest you start by using
it to confirm that when you scan with i2c -s you see something.

As it turns out, my logic analyser arrived today.

I got an oscilloscope onto pins 3 and 5 (GPIO2 and GPIO3), and "i2c -s" does not a jot on them.

I don't know if this helps, but the gpioctl utility thinks the pins are both inputs:

[***@grasshopper ~]# 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<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 03: 1 pin 3<IN>, 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>
pin 06: 1 pin 6<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 07: 0 pin 7<OUT>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 08: 0 pin 8<OUT>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 09: 0 pin 9<>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 10: 0 pin 10<>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 11: 0 pin 11<>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 12: 0 pin 12<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 13: 0 pin 13<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 14: 1 pin 14<>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 15: 1 pin 15<>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 16: 0 pin 16<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 17: 0 pin 17<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 18: 0 pin 18<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 19: 0 pin 19<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 20: 0 pin 20<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 21: 0 pin 21<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 22: 0 pin 22<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 23: 0 pin 23<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 24: 0 pin 24<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 25: 0 pin 25<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 26: 0 pin 26<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 27: 0 pin 27<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 28: 1 pin 28<>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 29: 0 pin 29<>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 30: 1 pin 30<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 31: 1 pin 31<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 32: 0 pin 32<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 33: 0 pin 33<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 34: 1 pin 34<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 35: 1 pin 35<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 36: 1 pin 36<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 37: 1 pin 37<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 38: 1 pin 38<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 39: 1 pin 39<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 40: 0 pin 40<>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 41: 0 pin 41<>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 42: 0 pin 42<OUT>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 43: 1 pin 43<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 44: 1 pin 44<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 45: 1 pin 45<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 46: 0 pin 46<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 47: 0 pin 47<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 48: 0 pin 48<>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 49: 0 pin 49<PU>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 50: 0 pin 50<PU>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 51: 0 pin 51<PU>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 52: 0 pin 52<PU>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 53: 0 pin 53<PU>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>

M
--
Mark R V Murray

[Mark Millard via freebsd-arm]

Post by Mark Murray

Post by Mark Murray

Post by Emmanuel Vadot
According to this document is this just to detect that the slave hold
the scl line too long so I don't think that this is the problem here.
If you have a scope or a logic analyzer I suggest you start by using
it to confirm that when you scan with i2c -s you see something.

As it turns out, my logic analyser arrived today.

I got an oscilloscope onto pins 3 and 5 (GPIO2 and GPIO3), and "i2c -s" does not a jot on them.

Looking around, I see:

https://github.com/raspberrypi/hats/blob/master/designguide.md

says:

QUOTE
The default state for all Bank 0 pins will be inputs with either a pull up or pull down. The default pull state can be found in the BCM2835 peripherals specificaion section 6.2 table 6-31 (see the "Pull" column). It will require positive software configuration to change the state of these pins.

The one exception to this rule is ID_SC and ID_SD. GPIO0 (ID_SD) and GPIO1 (ID_SC) will be switched to ALT0 (I2C-0) mode and probed for an EEPROM at boot time. These pins will revert to inputs once the probe sequence has completed.
END QUOTE

https://github.com/raspberrypi/hats has some other documents
as well.

If this note is redundant for you, sorry.

Post by Mark Murray
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<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 03: 1 pin 3<IN>, 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>
pin 06: 1 pin 6<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 07: 0 pin 7<OUT>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 08: 0 pin 8<OUT>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 09: 0 pin 9<>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 10: 0 pin 10<>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 11: 0 pin 11<>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 12: 0 pin 12<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 13: 0 pin 13<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 14: 1 pin 14<>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 15: 1 pin 15<>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 16: 0 pin 16<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 17: 0 pin 17<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 18: 0 pin 18<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 19: 0 pin 19<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 20: 0 pin 20<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 21: 0 pin 21<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 22: 0 pin 22<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 23: 0 pin 23<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 24: 0 pin 24<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 25: 0 pin 25<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 26: 0 pin 26<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 27: 0 pin 27<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 28: 1 pin 28<>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 29: 0 pin 29<>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 30: 1 pin 30<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 31: 1 pin 31<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 32: 0 pin 32<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 33: 0 pin 33<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 34: 1 pin 34<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 35: 1 pin 35<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 36: 1 pin 36<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 37: 1 pin 37<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 38: 1 pin 38<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 39: 1 pin 39<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 40: 0 pin 40<>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 41: 0 pin 41<>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 42: 0 pin 42<OUT>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 43: 1 pin 43<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 44: 1 pin 44<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 45: 1 pin 45<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 46: 0 pin 46<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 47: 0 pin 47<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 48: 0 pin 48<>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 49: 0 pin 49<PU>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 50: 0 pin 50<PU>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 51: 0 pin 51<PU>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 52: 0 pin 52<PU>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 53: 0 pin 53<PU>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

[Mark Murray]

Post by Mark Millard via freebsd-arm

Post by Mark Murray

Post by Mark Murray

Post by Emmanuel Vadot
According to this document is this just to detect that the slave hold
the scl line too long so I don't think that this is the problem here.
If you have a scope or a logic analyzer I suggest you start by using
it to confirm that when you scan with i2c -s you see something.

As it turns out, my logic analyser arrived today.

I got an oscilloscope onto pins 3 and 5 (GPIO2 and GPIO3), and "i2c -s" does not a jot on them.

https://github.com/raspberrypi/hats/blob/master/designguide.md

That's a useful document, thanks, but I'm not yet making much progress.

From a verbose boot, I extract the following gpio/i2c items:

[***@grasshopper ~]# dmesg | egrep 'gpio|i2c|iic'
gpio0: <BCM2708/2835 GPIO controller> mem 0x7e200000-0x7e2000b3 irq 14,15 on simplebus0
gpiobus0: <OFW GPIO bus> on gpio0
gpio0: set pin 9 to func 4
gpio0: set pin 10 to func 4
gpio0: set pin 11 to func 4
gpio0: set pin 8 to func 1
gpio0: set pin 7 to func 1
Processing 1 pin-config node(s) in pinctrl-0 for ***@7e804000 <<< ============= Something here?
gpio0: set pin 40 to func 4
gpio0: set pin 41 to func 4
gpio0: set pin 48 to func 7, pull 0
gpio0: set pin 49 to func 7, pull 2
gpio0: set pin 50 to func 7, pull 2
gpio0: set pin 51 to func 7, pull 2
gpio0: set pin 52 to func 7, pull 2
gpio0: set pin 53 to func 7, pull 2
gpio1: <Raspberry Pi Firmware GPIO controller> on bcm2835_firmware0
gpiobus1: <GPIO bus> on gpio1
gpioc0: <GPIO controller> on gpio0
simplebus0: <***@7e205000> mem 0x7e205000-0x7e2051ff irq 19 disabled compat brcm,bcm2711-i2c (no driver attached)
simplebus0: <i2c0mux> disabled compat i2c-mux-pinctrl (no driver attached)
iichb0: <BCM2708/2835 BSC controller> mem 0x7e804000-0x7e804fff irq 26 on simplebus0
simplebus0: <***@7e205600> mem 0x7e205600-0x7e2057ff irq 50 disabled compat brcm,bcm2711-i2c (no driver attached)
simplebus0: <***@7e205800> mem 0x7e205800-0x7e2059ff irq 51 disabled compat brcm,bcm2711-i2c (no driver attached)
simplebus0: <***@7e205a00> mem 0x7e205a00-0x7e205bff irq 52 disabled compat brcm,bcm2711-i2c (no driver attached)
simplebus0: <***@7e205c00> mem 0x7e205c00-0x7e205dff irq 53 disabled compat brcm,bcm2711-i2c (no driver attached)
simplebus0: <***@7ef04500> mem 0x7ef04500-0x7ef045ff,0x7ef00b00-0x7ef00dff disabled compat brcm,bcm2711-hdmi-i2c (no driver attached)
simplebus0: <***@7ef09500> mem 0x7ef09500-0x7ef095ff,0x7ef05b00-0x7ef05dff disabled compat brcm,bcm2711-hdmi-i2c (no driver attached)
gpioc1: <GPIO controller> on gpio1
simplebus0: <gpiomem> mem 0x7e200000-0x7e200fff compat brcm,bcm2835-gpiomem (no driver attached)
gpioled0: <GPIO LEDs> on ofwbus0
ofwbus0: <sd_io_1v8_reg> compat regulator-gpio (no driver attached)
iicbus0: <OFW I2C bus>usbus0: 5.0Gbps Super Speed USB v3.0
on iichb0
iic0: <I2C generic I/O> on iicbus0

The iic/i2c device is there, yet the physical pins on the RPI4 8GB are vigourously resisting doing anything at all. Does the above look OK to you folks who are in the know?

I decompiled the .dtb file to see if anything looked wrong (trying to follow whats happening in the .dts source files makes my brain hurt):

[***@grasshopper ~]# ls -al /boot/msdos/
:
-rwxr-xr-x 1 root wheel 49090 Mar 3 13:29 bcm2711-rpi-4-b-BACKUP.dtb
-rwxr-xr-x 1 root wheel 49089 Apr 30 07:20 bcm2711-rpi-4-b.dtb
-rwxr-xr-x 1 root wheel 56933 Apr 30 07:19 bcm2711-rpi-4-b.dts
:

I did find this snippet:

***@7e804000 {

compatible = "brcm,bcm2711-i2c", "brcm,bcm2835-i2c";
reg = <0x7e804000 0x1000>;
interrupts = <0x0 0x75 0x4>;
clocks = <0x7 0x14>;
#address-cells = <0x1>;
#size-cells = <0x0>;
pinctrl-names = "default";
pinctrl-0 = <0x17>;
clock-frequency = <0x186a0>;
phandle = <0x35>;
status = "disabled";
};

... and I didn't like the look of that ' status = "disabled"; ' line, but removing it, recompiling and rebooting had no effect. I2c is all over that .dts, and its confusing the hell out of me. Does pinctrl-0 have something to do with this? The pins 2/3 need to be configured to be BCM2835_FSEL_ALT0 (FSEL[2-3]=4), and pinctrl-0 is 0x17, but that doesn't seem to help register GPFSEL0 fields FSEL3(11:9) and FSEL(8:6).

Somebody must have this working?! :-)

Post by Mark Millard via freebsd-arm
If this note is redundant for you, sorry.

I'm not sure yet - the information definitely adds to what I know, but I'm still too new to this to put it together properly,, and I can only do it in short bursts of time (because life!), so thanks!

M
--
Mark R V Murray

--
Mark R V Murray

[Klaus Küchemann via freebsd-arm]

Post by Mark Millard via freebsd-arm
https://github.com/raspberrypi/hats/blob/master/designguide.md

...

Post by Mark Millard via freebsd-arm
That's a useful document, thanks, but I'm not yet making much progress.……

…..

Post by Mark Millard via freebsd-arm
. The pins 2/3 need to be configured to be BCM2835_FSEL_ALT0 (FSEL[2-3]=4), and pinctrl-0 is 0x17, but that doesn’t seem to help register GPFSEL0 fields FSEL3(11:9) and FSEL(8:6).
Mark R V Murray

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


K.

[Mark Murray]

Post by Klaus Küchemann via freebsd-arm
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!


Thank you!

M
--
Mark R V Murray

[Emmanuel Vadot]

On Sat, 1 May 2021 12:48:07 +0100

Post by Mark Murray

Post by Klaus Küchemann via freebsd-arm
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!
Thank you!
M
--
Mark R V Murray

This shouldn't be needed at all.
If we need to rely on the firmware to make basic pinctrl stuff working
it just means that the pinctrl driver isn't complete for RPI4.

[Mark Murray]

Post by Emmanuel Vadot
This shouldn't be needed at all.
If we need to rely on the firmware to make basic pinctrl stuff working
it just means that the pinctrl driver isn't complete for RPI4.

Good point, but for now it a) proves that the BSC works on RPI4 8GB, and b) allows to to stop Yak-Shaving for now and get back to my I2C project :-).

(My next (lower priority) problem is to break the UART away from the console such that the console is only the inbuilt video + usb KB and mouse, and the UART is an ordinary /dev/tty* and /dev/cu* device set).

M
--
Mark R V Murray

[Hrant Dadivanyan]

Yes, this helps me too:
iichb0: <BCM2708/2835 BSC controller> mem 0x7e804000-0x7e804fff irq 26
on simplebus0
iicbus0: <OFW I2C bus> on iichb0
iic0: <I2C generic I/O> on iicbus0
ds32310: <Maxim DS3231 RTC> at addr 0xd0 on iicbus0
ds32310: registered as a time-of-day clock, resolution 1.000000s

Thank you!
Hrant

Post by Mark Murray

Post by Klaus Küchemann via freebsd-arm
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!
Thank you!
M
--
Mark R V Murray

[Mark Millard via freebsd-arm]

Post by Mark Murray

Post by Klaus Küchemann via freebsd-arm
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.)

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

[Emmanuel Vadot]

On Sat, 1 May 2021 08:31:37 -0700

Post by Mark Millard via freebsd-arm

Post by Mark Murray

Post by Klaus Küchemann via freebsd-arm
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.)
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-arm

This is supposed to be done by bcm2835_gpio
See
https://cgit.freebsd.org/src/tree/sys/arm/broadcom/bcm2835/bcm2835_gpio.c#n805

[Mark Millard via freebsd-arm]

Post by Mark Millard via freebsd-arm

Post by Mark Murray

Post by Klaus Küchemann via freebsd-arm
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/***@7e200000,/***@1/__overlay__)
MESS:00:00:06.428737:0: dtdebug: merge_fragment(/soc/***@7e200000/mmc_pins,/***@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/***@7e200000/uart0_pins,/***@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/***@7e200000/bt_pins,/***@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,/***@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/***@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/***@7e200000/i2c1_gpio2";
. . .
i2c3_gpio2 = "/soc/***@7e200000/i2c3_gpio2";
. . .
uart2_ctsrts_gpio2 = "/soc/***@7e200000/uart2_ctsrts_gpio2";
. . .
dpi_18bit_gpio2 = "/soc/***@7e200000/dpi_18bit_gpio2";
. . .
i2c1_pins = "/soc/***@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/***@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/***@7e804000,/***@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/***@7e200000/i2c1,/***@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=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)

[Mark Millard via freebsd-arm]

Post by Mark Millard via freebsd-arm

Post by Mark Millard via freebsd-arm

Post by Mark Murray

Post by Klaus Küchemann via freebsd-arm
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
In BCM2835-ARM-Peripherals.pdf I see that the bits are
Address Field Name Description Size Read/ Write
0x 7E20 0000 GPFSEL0 GPIO Function Select 0 32 R/W
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
100 = GPIO Pin ? takes alternate function 0
(so 0x4 shifted over)
With dtdebug enabled in config.txt for the RPi firmware
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.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.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.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.794694:0: dtdebug: +prop(serial0)
MESS:00:00:06.800962:0: dtdebug: +prop(serial1)
MESS:00:00:06.805366:0: dtdebug: merge_fragment() end
Using DTB provided by EFI at 0x7ef0000.
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
. . .
. . .
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];
. . .
. . .
. . .
. . .
. . .
. . .
There is sort of an overall alt0 --that omits mention
. . .
alt0 {
brcm,pins = <0x00000004 0x00000005 0x00000007 0x00000008 0x00000009 0x0000000a 0x0000000b>;
brcm,function = <0x00000004>;
phandle = <0x00000095>;
};
. . .
. . .
The same was true with gpio=2,3=a0 in the config.txt .
chosen {
- kaslr-seed = <0x3bab60e6 0x2352e756>;
+ kaslr-seed = <0x2adcd524 0x37345f4c>;
rpi-boardrev-ext = <0x00000000>;
But I have confirmed a difference via how pins 2 and
# 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>
. . .
/usr/local/share/rpi-firmware/overlays/i2c1.dtbo
(just based on the "i2c1" part of the naming).
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")
. . .
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.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.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.

Post by Mark Millard via freebsd-arm
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.
enable_uart=1
uart_2ndstage=1
dtdebug=1
in config.txt to get more output on the serial
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)

[Mark Millard via freebsd-arm]

Post by Mark Millard via freebsd-arm

Post by Mark Millard via freebsd-arm

Post by Mark Murray

Post by Klaus Küchemann via freebsd-arm
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.]
. . .

Going more in a code exploration direction I found evidence
of sysctl for:

# sysctl dev.gpio.0.pin.3.function dev.gpio.0.pin.2.function
dev.gpio.0.pin.3.function: input
dev.gpio.0.pin.2.function: input

and for:

# sysctl dev.gpio.0.pin.3.function=alt0 dev.gpio.0.pin.2.function=alt0
dev.gpio.0.pin.3.function: input -> alt0
dev.gpio.0.pin.2.function: input -> alt0

# sysctl dev.gpio.0.pin.3.function dev.gpio.0.pin.2.function
dev.gpio.0.pin.3.function: alt0
dev.gpio.0.pin.2.function: alt0

# 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>
. . .

So it appears that there is no need of the config.txt
way of doing it and there is both command-line and
code-internal ways of controlling the assignments (via
the internal way of initiating sysctl activity).

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

[Mark Murray]

Hi Mark,

Post by Mark Millard via freebsd-arm
[I was given a code hint that I've not investigated yet.]
But going in a different direction, based on my default

... and a whole lot more really helpful diagnosis over several emails.

Thank you VERY much! it will take me a while to digest this, but digest it I will.

Ultimately, it would be good for a "make buildworld; make installworld" on an RPi to install the in-source FDT, and for it to be correct, such that it doesn't take some trickier port modification to have a working FDT. This is worth taking on as a project, but I won't get to it very soon.

M
--
Mark R V Murray

[Emmanuel Vadot]

On Sun, 2 May 2021 11:14:53 +0100

Post by Hrant Dadivanyan
Hi Mark,

Post by Mark Millard via freebsd-arm
[I was given a code hint that I've not investigated yet.]
But going in a different direction, based on my default

... and a whole lot more really helpful diagnosis over several emails.
Thank you VERY much! it will take me a while to digest this, but digest it I will.
Ultimately, it would be good for a "make buildworld; make installworld" on an RPi to install the in-source FDT, and for it to be correct, such that it doesn't take some trickier port modification to have a working FDT. This is worth taking on as a project, but I won't get to it very soon.
M
--
Mark R V Murray

Installing and dtb in the ESP is still WIP but for RPI things are
different.
We made a decision to use the dtb shipped with the firmware a long
time ago and most of our drivers are made for them.
I've never looked at how much work (if any) is needed to have the same
functionality when booting with a dtb compiled from
sys/contrib/device-tree.
One of the main advantage of using the dtb from rpi-firmware is that
someone following a random blog post saying that one should use one
of the overlays provided by the firmware will mostly work (this can
also be a disadvantage if that doesn't work).

[Mark Millard via freebsd-arm]

Post by Mark Murray

Post by Mark Millard via freebsd-arm
[I was given a code hint that I've not investigated yet.]
But going in a different direction, based on my default

... and a whole lot more really helpful diagnosis over several emails.
Thank you VERY much! it will take me a while to digest this, but digest it I will.
Ultimately, it would be good for a "make buildworld; make installworld" on an RPi to install the in-source FDT, and for it to be correct, such that it doesn't take some trickier port modification to have a working FDT. This is worth taking on as a project, but I won't get to it very soon.

Linux and the foundation do not even agree about various .dtb names
(or content). And some linux distributions targeting the RPi*'s
use the foundation's .dtb files in preference to the linux mainline
ones.

For example, fedora uses the foundation's files (same names
as FreeBSD ends up with). Fedora 34:

# ls -ld /boot/efi/*.dtb
-rwx------. 1 root root 26745 Feb 23 07:35 /boot/efi/bcm2709-rpi-2-b.dtb
-rwx------. 1 root root 26894 Feb 23 07:35 /boot/efi/bcm2710-rpi-2-b.dtb
-rwx------. 1 root root 28392 Feb 23 07:35 /boot/efi/bcm2710-rpi-3-b.dtb
-rwx------. 1 root root 29011 Feb 23 07:35 /boot/efi/bcm2710-rpi-3-b-plus.dtb
-rwx------. 1 root root 26890 Feb 23 07:35 /boot/efi/bcm2710-rpi-cm3.dtb
-rwx------. 1 root root 49198 Apr 9 07:11 /boot/efi/bcm2711-rpi-400.dtb
-rwx------. 1 root root 49218 Mar 24 08:12 /boot/efi/bcm2711-rpi-4-b.dtb
-rwx------. 1 root root 49892 Apr 9 07:11 /boot/efi/bcm2711-rpi-cm4.dtb

By contrast, ubuntu uses the linux .dtb's. Note the bcm2837*.dtb
names in ubuntu 21.04 (instead of bcm2709*.dtb and bcm2710*.dtb like
naming):

# ls -ld /boot/firmware/*.dtb
-rwxr-xr-x 1 root root 26914 Apr 22 21:21 /boot/firmware/bcm2710-rpi-2-b.dtb
-rwxr-xr-x 1 root root 29031 Apr 22 21:21 /boot/firmware/bcm2710-rpi-3-b-plus.dtb
-rwxr-xr-x 1 root root 28412 Apr 22 21:21 /boot/firmware/bcm2710-rpi-3-b.dtb
-rwxr-xr-x 1 root root 26910 Apr 22 21:21 /boot/firmware/bcm2710-rpi-cm3.dtb
-rwxr-xr-x 1 root root 49254 Apr 22 21:21 /boot/firmware/bcm2711-rpi-4-b.dtb
-rwxr-xr-x 1 root root 48910 Apr 22 21:21 /boot/firmware/bcm2711-rpi-400.dtb
-rwxr-xr-x 1 root root 49318 Apr 22 21:21 /boot/firmware/bcm2711-rpi-cm4.dtb
-rwxr-xr-x 1 root root 20140 Apr 22 21:21 /boot/firmware/bcm2837-rpi-3-a-plus.dtb
-rwxr-xr-x 1 root root 21009 Apr 22 21:21 /boot/firmware/bcm2837-rpi-3-b-plus.dtb
-rwxr-xr-x 1 root root 20545 Apr 22 21:21 /boot/firmware/bcm2837-rpi-3-b.dtb
-rwxr-xr-x 1 root root 19872 Apr 22 21:21 /boot/firmware/bcm2837-rpi-cm3-io3.dtb
-rwxr-xr-x 1 root root 1559 Apr 3 06:16 /boot/firmware/overlay_map.dtb

The RPiFirmware has special config.txt support for using upstream
kernels that expect the linux naming and content. For example:

QUOTE
upstream_kernel

If upstream_kernel=1 is used, the firmware sets os_prefix to "upstream/", unless it has been explicitly set to something else, but like other os_prefixvalues it will be ignored if the required kernel and .dtb file can't be found when using the prefix.

The firmware will also prefer upstream Linux names for DTBs (bcm2837-rpi-3-b.dtb instead of bcm2710-rpi-3-b.dtb, for example). If the upstream file isn't found the firmware will load the downstream variant instead and automatically apply the "upstream" overlay to make some adjustments. Note that this process happens after the os_prefix has been finalised.
ENDQUOTE

See https://www.raspberrypi.org/documentation/configuration/config-txt/boot.md
for os_prefix and overlay_prefix information as well.

From what I can tell, it appears that the linux .dtb's are less tested
by being less used, so possibly having more problems, not fewer. And
FreeBSD itself would have to have its kernel updated to deal with the
differences (or to support both ways). It is not just a build environment
change if I understand right.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

[Mark Millard via freebsd-arm]

Post by Mark Millard via freebsd-arm

Post by Mark Murray

Post by Mark Millard via freebsd-arm
[I was given a code hint that I've not investigated yet.]
But going in a different direction, based on my default

... and a whole lot more really helpful diagnosis over several emails.
Thank you VERY much! it will take me a while to digest this, but digest it I will.
Ultimately, it would be good for a "make buildworld; make installworld" on an RPi to install the in-source FDT, and for it to be correct, such that it doesn't take some trickier port modification to have a working FDT. This is worth taking on as a project, but I won't get to it very soon.

Linux and the foundation do not even agree about various .dtb names
(or content). And some linux distributions targeting the RPi*'s
use the foundation's .dtb files in preference to the linux mainline
ones.
For example, fedora uses the foundation's files (same names
# ls -ld /boot/efi/*.dtb
-rwx------. 1 root root 26745 Feb 23 07:35 /boot/efi/bcm2709-rpi-2-b.dtb
-rwx------. 1 root root 26894 Feb 23 07:35 /boot/efi/bcm2710-rpi-2-b.dtb
-rwx------. 1 root root 28392 Feb 23 07:35 /boot/efi/bcm2710-rpi-3-b.dtb
-rwx------. 1 root root 29011 Feb 23 07:35 /boot/efi/bcm2710-rpi-3-b-plus.dtb
-rwx------. 1 root root 26890 Feb 23 07:35 /boot/efi/bcm2710-rpi-cm3.dtb
-rwx------. 1 root root 49198 Apr 9 07:11 /boot/efi/bcm2711-rpi-400.dtb
-rwx------. 1 root root 49218 Mar 24 08:12 /boot/efi/bcm2711-rpi-4-b.dtb
-rwx------. 1 root root 49892 Apr 9 07:11 /boot/efi/bcm2711-rpi-cm4.dtb
By contrast, ubuntu uses the linux .dtb's. Note the bcm2837*.dtb
names in ubuntu 21.04 (instead of bcm2709*.dtb and bcm2710*.dtb like
# ls -ld /boot/firmware/*.dtb
-rwxr-xr-x 1 root root 26914 Apr 22 21:21 /boot/firmware/bcm2710-rpi-2-b.dtb
-rwxr-xr-x 1 root root 29031 Apr 22 21:21 /boot/firmware/bcm2710-rpi-3-b-plus.dtb
-rwxr-xr-x 1 root root 28412 Apr 22 21:21 /boot/firmware/bcm2710-rpi-3-b.dtb
-rwxr-xr-x 1 root root 26910 Apr 22 21:21 /boot/firmware/bcm2710-rpi-cm3.dtb
-rwxr-xr-x 1 root root 49254 Apr 22 21:21 /boot/firmware/bcm2711-rpi-4-b.dtb
-rwxr-xr-x 1 root root 48910 Apr 22 21:21 /boot/firmware/bcm2711-rpi-400.dtb
-rwxr-xr-x 1 root root 49318 Apr 22 21:21 /boot/firmware/bcm2711-rpi-cm4.dtb
-rwxr-xr-x 1 root root 20140 Apr 22 21:21 /boot/firmware/bcm2837-rpi-3-a-plus.dtb
-rwxr-xr-x 1 root root 21009 Apr 22 21:21 /boot/firmware/bcm2837-rpi-3-b-plus.dtb
-rwxr-xr-x 1 root root 20545 Apr 22 21:21 /boot/firmware/bcm2837-rpi-3-b.dtb
-rwxr-xr-x 1 root root 19872 Apr 22 21:21 /boot/firmware/bcm2837-rpi-cm3-io3.dtb
-rwxr-xr-x 1 root root 1559 Apr 3 06:16 /boot/firmware/overlay_map.dtb
The RPiFirmware has special config.txt support for using upstream
QUOTE
upstream_kernel
If upstream_kernel=1 is used, the firmware sets os_prefix to "upstream/", unless it has been explicitly set to something else, but like other os_prefixvalues it will be ignored if the required kernel and .dtb file can't be found when using the prefix.
The firmware will also prefer upstream Linux names for DTBs (bcm2837-rpi-3-b.dtb instead of bcm2710-rpi-3-b.dtb, for example). If the upstream file isn't found the firmware will load the downstream variant instead and automatically apply the "upstream" overlay to make some adjustments. Note that this process happens after the os_prefix has been finalised.
ENDQUOTE
See https://www.raspberrypi.org/documentation/configuration/config-txt/boot.md
for os_prefix and overlay_prefix information as well.
From what I can tell, it appears that the linux .dtb's are less tested
by being less used, so possibly having more problems, not fewer. And
FreeBSD itself would have to have its kernel updated to deal with the
differences (or to support both ways). It is not just a build environment
change if I understand right.

There is another implication: the RPi firmware loaded and uses
the .dtb files and also makes dynamic adjustments to provide
what it does to U-Boot, which in turn can do more adjsutments
for what it provides to the FreeBSD loader.

Having the kernel use different .dtb built from other sources
without having the RPi firmware and U-Boot also use the same
.dtb is asking for mismatches and other troubles.

Thus any .dtb generated and used needs to be tested for the
earlier stages handling the alternate .dtb's. Compatibility
would not be a local-to-FreeBSD concern overall.

It is not obvious to me that alternate .dtb files make things
simpler for knowing what will work vs. not.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

[Mark Millard via freebsd-arm]

Post by Mark Murray

Post by Mark Millard via freebsd-arm
[I was given a code hint that I've not investigated yet.]
But going in a different direction, based on my default

... and a whole lot more really helpful diagnosis over several emails.
Thank you VERY much! it will take me a while to digest this, but digest it I will.
Ultimately, it would be good for a "make buildworld; make installworld" on an RPi to install the in-source FDT, and for it to be correct, such that it doesn't take some trickier port modification to have a working FDT. This is worth taking on as a project, but I won't get to it very soon.

When I collected and sent out boot -v gpio/i2c/iic information
(case independent) for my context, one of the things in it was
a "regfix0: Cannot set GPIO pin" notice with "REGNODE_INIT
failed" and "regfix0: Cannot register regulator" lines as well:

. . .
gpio0: set pin 53 to func 7, pull 2
gpio1: <Raspberry Pi Firmware GPIO controller> on bcm2835_firmware0
gpiobus1: <GPIO bus> on gpio1
regfix0: Cannot set GPIO pin: 6
REGNODE_INIT failed: 6
regfix0: Cannot register regulator.
mbox0: <BCM2835 VideoCore Mailbox> mem 0x7e00b880-0x7e00b8bf irq 13 on simplebus0
. . .

Do you get the same?

I wonder if it might interfere with part of the gpio*
initialization.

(I was testing a 2021-Mar-12 vintage of FreeBSD but with
more recent RPi* and u-boot materials.)

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

[Emmanuel Vadot]

On Thu, 29 Apr 2021 17:57:45 +0100

Post by Mark Murray

Post by Mark Murray

Post by Emmanuel Vadot
According to this document is this just to detect that the slave hold
the scl line too long so I don't think that this is the problem here.
If you have a scope or a logic analyzer I suggest you start by using
it to confirm that when you scan with i2c -s you see something.

As it turns out, my logic analyser arrived today.

I got an oscilloscope onto pins 3 and 5 (GPIO2 and GPIO3), and "i2c -s" does not a jot on them.

And this is with the i2cX.dtbo right ?
Can you share the full dmesg please ?
I don't remember if the gpio/pinctrl controller in RPI still sees the
pins when they are configured to an alt function or not but that does
seems a bit strange yes.

Please share a full dmesg as I want to confirm that the pins are
configured for i2c function.

Post by Mark Murray
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<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 03: 1 pin 3<IN>, 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>
pin 06: 1 pin 6<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 07: 0 pin 7<OUT>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 08: 0 pin 8<OUT>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 09: 0 pin 9<>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 10: 0 pin 10<>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 11: 0 pin 11<>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 12: 0 pin 12<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 13: 0 pin 13<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 14: 1 pin 14<>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 15: 1 pin 15<>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 16: 0 pin 16<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 17: 0 pin 17<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 18: 0 pin 18<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 19: 0 pin 19<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 20: 0 pin 20<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 21: 0 pin 21<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 22: 0 pin 22<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 23: 0 pin 23<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 24: 0 pin 24<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 25: 0 pin 25<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 26: 0 pin 26<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 27: 0 pin 27<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 28: 1 pin 28<>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 29: 0 pin 29<>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 30: 1 pin 30<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 31: 1 pin 31<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 32: 0 pin 32<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 33: 0 pin 33<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 34: 1 pin 34<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 35: 1 pin 35<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 36: 1 pin 36<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 37: 1 pin 37<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 38: 1 pin 38<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 39: 1 pin 39<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 40: 0 pin 40<>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 41: 0 pin 41<>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 42: 0 pin 42<OUT>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 43: 1 pin 43<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 44: 1 pin 44<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 45: 1 pin 45<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 46: 0 pin 46<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 47: 0 pin 47<IN>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 48: 0 pin 48<>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 49: 0 pin 49<PU>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 50: 0 pin 50<PU>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 51: 0 pin 51<PU>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 52: 0 pin 52<PU>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
pin 53: 0 pin 53<PU>, caps:<IN,OUT,PU,PD,INTRLL,INTRLH,INTRER,INTREF,INTREB>
M
--
Mark R V Murray

[Mark Millard via freebsd-arm]

Post by Emmanuel Vadot
On Thu, 29 Apr 2021 17:57:45 +0100

Post by Mark Murray

Post by Mark Murray

Post by Emmanuel Vadot
According to this document is this just to detect that the slave hold
the scl line too long so I don't think that this is the problem here.
If you have a scope or a logic analyzer I suggest you start by using
it to confirm that when you scan with i2c -s you see something.

As it turns out, my logic analyser arrived today.

I got an oscilloscope onto pins 3 and 5 (GPIO2 and GPIO3), and "i2c -s" does not a jot on them.

And this is with the i2cX.dtbo right ?
Can you share the full dmesg please ?
I don't remember if the gpio/pinctrl controller in RPI still sees the
pins when they are configured to an alt function or not but that does
seems a bit strange yes.
Please share a full dmesg as I want to confirm that the pins are
configured for i2c function.

Post by Mark Murray
. . .

In case you look at some of the notes I've sent out,
my RPi4B 8 GiBYte context shows:

The RPi4's context is back as of 2021-Mar-12:

merge-base: 7381bbee29df959e88ec59866cf2878263e7f3b2
merge-base: CommitDate: 2021-03-12 20:29:42 +0000
7381bbee29df (freebsd/main, freebsd/HEAD, pure-src, main) cam: Run all XPT_ASYNC ccbs in a dedicated thread
n245444 (--first-parent --count for merge-base)

Boot verbose reported for case independent gpio|i2c|iic
in dmesg -a from a boot -v :

gic0: <ARM Generic Interrupt Controller> mem 0x40041000-0x40041fff,0x40042000-0x40043fff,0x40044000-0x40045fff,0x40046000-0x40047fff irq 30 on simplebus0
gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 256
gpio0: <BCM2708/2835 GPIO controller> mem 0x7e200000-0x7e2000b3 irq 14,15 on simplebus0
gpiobus0: <OFW GPIO bus> on gpio0
Processing 1 pin-config node(s) in pinctrl-0 for ***@7e201000
Processing 2 pin-config node(s) in pinctrl-0 for ***@7e204000
gpio0: set pin 9 to func 4
gpio0: set pin 10 to func 4
gpio0: set pin 11 to func 4
gpio0: set pin 8 to func 1
gpio0: set pin 7 to func 1
Processing 1 pin-config node(s) in pinctrl-0 for ***@7e804000
Processing 1 pin-config node(s) in pinctrl-0 for bcm2835_audio
gpio0: set pin 40 to func 4
gpio0: set pin 41 to func 4
Processing 1 pin-config node(s) in pinctrl-0 for ***@7e300000
gpio0: set pin 48 to func 7, pull 0
gpio0: set pin 49 to func 7, pull 2
gpio0: set pin 50 to func 7, pull 2
gpio0: set pin 51 to func 7, pull 2
gpio0: set pin 52 to func 7, pull 2
gpio0: set pin 53 to func 7, pull 2
gpio1: <Raspberry Pi Firmware GPIO controller> on bcm2835_firmware0
gpiobus1: <GPIO bus> on gpio1
regfix0: Cannot set GPIO pin: 6
REGNODE_INIT failed: 6
regfix0: Cannot register regulator.
mbox0: <BCM2835 VideoCore Mailbox> mem 0x7e00b880-0x7e00b8bf irq 13 on simplebus0
gpioregulator0: <GPIO controlled regulator> on ofwbus0
. . .
gpioc0: <GPIO controller> on gpio0
uart0: <PrimeCell UART (PL011)> mem 0x7e201000-0x7e2011ff irq 16 on simplebus0
uart0: console (115200,n,8,1)
uart0: fast interrupt
uart0: PPS capture mode: DCD
simplebus0: <***@7e202000> mem 0x7e202000-0x7e2020ff irq 17 disabled compat brcm,bcm2835-sdhost (no driver attached)
simplebus0: <***@7e203000> mem 0x7e203000-0x7e203023 disabled compat brcm,bcm2835-i2s (no driver attached)
spi0: <BCM2708/2835 SPI controller> mem 0x7e204000-0x7e2041ff irq 18 on simplebus0
spibus0: <OFW SPI bus> on spi0
spibus0: <unknown card> at cs 0 mode 0
spibus0: <unknown card> at cs 1 mode 0
simplebus0: <***@7e205000> mem 0x7e205000-0x7e2051ff irq 19 disabled compat brcm,bcm2711-i2c (no driver attached)
simplebus0: <i2c0mux> disabled compat i2c-mux-pinctrl (no driver attached)
simplebus0: <***@7e208000> mem 0x7e208000-0x7e20808b disabled compat brcm,bcm2835-dpi (no driver attached)
simplebus0: <***@7e209000> mem 0x7e209000-0x7e209077 irq 20 disabled compat brcm,bcm2835-dsi0 (no driver attached)
simplebus0: <***@7e215000> mem 0x7e215000-0x7e215007 compat brcm,bcm2835-aux (no driver attached)
simplebus0: <***@7e215040> mem 0x7e215040-0x7e21507f irq 21 disabled compat brcm,bcm2835-aux-uart (no driver attached)
simplebus0: <***@7e215080> mem 0x7e215080-0x7e2150bf irq 22 disabled compat brcm,bcm2835-aux-spi (no driver attached)
simplebus0: <***@7e2150c0> mem 0x7e2150c0-0x7e2150ff irq 23 disabled compat brcm,bcm2835-aux-spi (no driver attached)
simplebus0: <***@7e20c000> mem 0x7e20c000-0x7e20c027 disabled compat brcm,bcm2835-pwm (no driver attached)
simplebus0: <***@7e400000> mem 0x7e400000-0x7e405fff irq 24 disabled compat brcm,bcm2711-hvs (no driver attached)
simplebus0: <***@7e700000> mem 0x7e700000-0x7e70008b irq 25 disabled compat brcm,bcm2711-dsi1 (no driver attached)
iichb0: <BCM2708/2835 BSC controller> mem 0x7e804000-0x7e804fff irq 26 on simplebus0
. . .
simplebus0: <***@7e205600> mem 0x7e205600-0x7e2057ff irq 50 disabled compat brcm,bcm2711-i2c (no driver attached)
simplebus0: <***@7e205800> mem 0x7e205800-0x7e2059ff irq 51 disabled compat brcm,bcm2711-i2c (no driver attached)
simplebus0: <***@7e205a00> mem 0x7e205a00-0x7e205bff irq 52 disabled compat brcm,bcm2711-i2c (no driver attached)
simplebus0: <***@7e205c00> mem 0x7e205c00-0x7e205dff irq 53 disabled compat brcm,bcm2711-i2c (no driver attached)
simplebus0: <***@7e206000> mem 0x7e206000-0x7e2060ff irq 54 disabled compat brcm,bcm2711-pixelvalve0 (no driver attached)
simplebus0: <***@7e207000> mem 0x7e207000-0x7e2070ff irq 55 disabled compat brcm,bcm2711-pixelvalve1 (no driver attached)
simplebus0: <***@7e20a000> mem 0x7e20a000-0x7e20a0ff irq 56 disabled compat brcm,bcm2711-pixelvalve2 (no driver attached)
simplebus0: <***@7e20c800> mem 0x7e20c800-0x7e20c827 disabled compat brcm,bcm2835-pwm (no driver attached)
simplebus0: <***@7e216000> mem 0x7e216000-0x7e2160ff irq 57 disabled compat brcm,bcm2711-pixelvalve4 (no driver attached)
simplebus0: <***@7ec12000> mem 0x7ec12000-0x7ec120ff irq 58 disabled compat brcm,bcm2711-pixelvalve3 (no driver attached)
simplebus0: <***@7ef00000> mem 0x7ef00000-0x7ef0000f disabled compat brcm,brcm2711-dvp (no driver attached)
simplebus0: <interrupt-***@7ef00100> mem 0x7ef00100-0x7ef0012f irq 59 disabled compat brcm,bcm2711-l2-intc (no driver attached)
simplebus0: <***@7ef00700> mem 0x7ef00700-0x7ef009ff,0x7ef00300-0x7ef004ff,0x7ef00f00-0x7ef00f7f,0x7ef00f80-0x7ef00fff,0x7ef01b00-0x7ef01cff,0x7ef01f00-0x7ef022ff,0x7ef00200-0x7ef0027f,0x7ef04300-0x7ef043ff,0x7ef20000-0x7ef200ff,0x7ef00100-0x7ef0012f irq 60,61,62,63,64,65 disabled compat brcm,bcm2711-hdmi0 (no driver attached)
simplebus0: <***@7ef04500> mem 0x7ef04500-0x7ef045ff,0x7ef00b00-0x7ef00dff disabled compat brcm,bcm2711-hdmi-i2c (no driver attached)
simplebus0: <***@7ef05700> mem 0x7ef05700-0x7ef059ff,0x7ef05300-0x7ef054ff,0x7ef05f00-0x7ef05f7f,0x7ef05f80-0x7ef05fff,0x7ef06b00-0x7ef06cff,0x7ef06f00-0x7ef072ff,0x7ef00280-0x7ef002ff,0x7ef09300-0x7ef093ff,0x7ef20000-0x7ef200ff,0x7ef00100-0x7ef0012f irq 66,67,68,69,70,71 disabled compat brcm,bcm2711-hdmi1 (no driver attached)
simplebus0: <***@7ef09500> mem 0x7ef09500-0x7ef095ff,0x7ef05b00-0x7ef05dff disabled compat brcm,bcm2711-hdmi-i2c (no driver attached)
gpioc1: <GPIO controller> on gpio1
. . .
simplebus0: <gpiomem> mem 0x7e200000-0x7e200fff compat brcm,bcm2835-gpiomem (no driver attached)
. . .
gpioled0: <GPIO LEDs> on ofwbus0
. . .
iicbus0: <OFW I2C bus> on iichb0
usbus0: 5.0Gbps Super Speed USB v3.0
iic0: <I2C generic I/O> on iicbus0


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

[Mark Murray]

Post by Mark Millard via freebsd-arm
https://lists.freebsd.org/pipermail/freebsd-arm/2021-April/023687.html

Yes. No effect, apologies for not reporting.

That suggestion seems to require overlays that I on't even have, and works
around the problem by loading a GPIO bit-banging driver.

I'm looking to get the real hardware BSC going, as I want to do a fair bit of I2C I/O.

M
--
Mark R V Murray