ARM: socfpga: enclustra-sa2: issue with I2C1

ARM: socfpga: enclustra-sa2: issue with I2C1

[David Picard]

Hello,

@Stephen and Ian: I Cc you since I spotted you authored commits related 
to Intel SoC FPGA pin muxing.

I'm trying to enable the I2C1 bus on a Cyclone V-base module, mounted on 
a base board. The I2C1 lines connect to a 2.54mm header, on which I 
attached a I²C device with pull-up resistors at address 0x40.
https://www.enclustra.com/en/products/system-on-chip-modules/mercury-sa2/

I can't detect the I²C device, nor can I see any pulse on the SCL line, 
which is constantly at +3.3V.

I changed the pin muxing in Quartus, updated the handoff files, changed 
the devicetree. The I2C1 bus is visible in Barebox and Linux. More 
detail here:
https://community.altera.com/discussions/fpga-device/cyclone-v-hps-i2c1-issue-no-activity-on-bus/352583

As documented on the Barebox website, I generated the BSP files with the 
Quartus script bsp-create-settings and copied the handoff files to the 
Barebox build directory. After that, I could see that 
iocsr_config_cyclone5.c and pinmux_config.c had changed.
https://www.barebox.org/doc/2025.05.0/boards/socfpga.html#updating-handoff-files
https://www.intel.com/content/www/us/en/docs/programmable/683187/20-1/bsp-create-settings.html

If someone could give me some hint, that would be really great!

David

Re: ARM: socfpga: enclustra-sa2: issue with I2C1

[Steffen Trumtrar]

On 2026-04-23 at 14:00 +02, David Picard <david.picard@clermont.in2p3.fr> wrote:

Hi,

> Hello,
> 
> @Stephen and Ian: I Cc you since I spotted you authored commits related to Intel
> SoC FPGA pin muxing.
>

long time ago ;)

> I'm trying to enable the I2C1 bus on a Cyclone V-base module, mounted on a base
> board. The I2C1 lines connect to a 2.54mm header, on which I attached a I²C
> device with pull-up resistors at address 0x40.
> https://www.enclustra.com/en/products/system-on-chip-modules/mercury-sa2/
> 
> I can't detect the I²C device, nor can I see any pulse on the SCL line, which is
> constantly at +3.3V.
> 
> I changed the pin muxing in Quartus, updated the handoff files, changed the
> devicetree. The I2C1 bus is visible in Barebox and Linux. More detail here:
> https://community.altera.com/discussions/fpga-device/cyclone-v-hps-i2c1-issue-no-activity-on-bus/352583
>

I remember, that iocsr was 'underdocumented' to say the least...

Wasn't it possible to change drive strength and those settings or was that with Xilinx/Zynq?

> As documented on the Barebox website, I generated the BSP files with the Quartus
> script bsp-create-settings and copied the handoff files to the Barebox build
> directory. After that, I could see that iocsr_config_cyclone5.c and
> pinmux_config.c had changed.
> https://www.barebox.org/doc/2025.05.0/boards/socfpga.html#updating-handoff-files
> https://www.intel.com/content/www/us/en/docs/programmable/683187/20-1/bsp-create-settings.html
> 
> If someone could give me some hint, that would be really great!

I see, that the Terasic DE10 Nano uses i2c1. Maybe compare the changed iocsr with those?


Best regards,
Steffen

-- 
Pengutronix e.K.                | Dipl.-Inform. Steffen Trumtrar |
Steuerwalder Str. 21            | https://www.pengutronix.de/    |
31137 Hildesheim, Germany       | Phone: +49-5121-206917-0       |
Amtsgericht Hildesheim, HRA 2686| Fax:   +49-5121-206917-5555    |

Re: ARM: socfpga: enclustra-sa2: issue with I2C1

[David Picard]

Hi Stephen, thanks for your reply,

Pins SDA and SCL, GPIO51 and GPIO52 respectively, are specified with the 
I/O standard 3.3V LVCMOS and a drive strength of 2mA, which is way more 
than needed, given my 10K pull-up resistors (3.3 / 10K = 0.33mA). I know 
that 10K is bigger than the usual 2.2K, but probably not big enough to 
prevent any change on the SCL line. I just see a perfect flat line when 
I probe the bus.

I compared iocsr_config_cyclone5.c and pinmux_config.c in the 
terasic-de10-nano/ and enclustra-sa2/ directories. There are a lot of 
differences. But the lines that changed in enclustra-sa2/ when I tried 
to enable the I2C1 bus are now the same as in the terasic-de10-nano/ 
directory, which probably makes sense.

Does Barebox have to decipher every bit in those cryptic files?

David


Le 24/04/2026 à 09:27, Steffen Trumtrar a écrit :
> On 2026-04-23 at 14:00 +02, David Picard 
> <david.picard@clermont.in2p3.fr> wrote:
>
> Hi,
>
>> Hello,
>>
>> @Stephen and Ian: I Cc you since I spotted you authored commits 
>> related to Intel
>> SoC FPGA pin muxing.
>>
>
> long time ago ;)
>
>> I'm trying to enable the I2C1 bus on a Cyclone V-base module, mounted 
>> on a base
>> board. The I2C1 lines connect to a 2.54mm header, on which I attached 
>> a I²C
>> device with pull-up resistors at address 0x40.
>> https://www.enclustra.com/en/products/system-on-chip-modules/mercury-sa2/ 
>>
>>
>> I can't detect the I²C device, nor can I see any pulse on the SCL 
>> line, which is
>> constantly at +3.3V.
>>
>> I changed the pin muxing in Quartus, updated the handoff files, 
>> changed the
>> devicetree. The I2C1 bus is visible in Barebox and Linux. More detail 
>> here:
>> https://community.altera.com/discussions/fpga-device/cyclone-v-hps-i2c1-issue-no-activity-on-bus/352583 
>>
>>
>
> I remember, that iocsr was 'underdocumented' to say the least...
>
> Wasn't it possible to change drive strength and those settings or was 
> that with Xilinx/Zynq?
>
>> As documented on the Barebox website, I generated the BSP files with 
>> the Quartus
>> script bsp-create-settings and copied the handoff files to the 
>> Barebox build
>> directory. After that, I could see that iocsr_config_cyclone5.c and
>> pinmux_config.c had changed.
>> https://www.barebox.org/doc/2025.05.0/boards/socfpga.html#updating-handoff-files 
>>
>> https://www.intel.com/content/www/us/en/docs/programmable/683187/20-1/bsp-create-settings.html 
>>
>>
>> If someone could give me some hint, that would be really great!
>
> I see, that the Terasic DE10 Nano uses i2c1. Maybe compare the changed 
> iocsr with those?
>
>
> Best regards,
> Steffen
>

Re: ARM: socfpga: enclustra-sa2: issue with I2C1

[Steffen Trumtrar]

On 2026-04-27 at 12:09 +02, David Picard <david.picard@clermont.in2p3.fr> wrote:

Hi,

> Hi Stephen, thanks for your reply,
> 
> Pins SDA and SCL, GPIO51 and GPIO52 respectively, are specified with the I/O
> standard 3.3V LVCMOS and a drive strength of 2mA, which is way more than needed,
> given my 10K pull-up resistors (3.3 / 10K = 0.33mA). I know that 10K is bigger
> than the usual 2.2K, but probably not big enough to prevent any change on the
> SCL line. I just see a perfect flat line when I probe the bus.
>

:(

> I compared iocsr_config_cyclone5.c and pinmux_config.c in the terasic-de10-nano/
> and enclustra-sa2/ directories. There are a lot of differences. But the lines
> that changed in enclustra-sa2/ when I tried to enable the I2C1 bus are now the
> same as in the terasic-de10-nano/ directory, which probably makes sense.
>

Makes sence, yes and was what I hoped for. But, doesn't seem to change anything.

> Does Barebox have to decipher every bit in those cryptic files?
>

barebox knows nothing about the meaning of the iocsr registers. Those values a just written to the hardware and can't be changed afterwards.
AFAIK there still is no linux driver that might read and decipher the settings.

Sadly, I don't have any more ideas at the top of my head why it doesn't work. Everything sounds correct.


Best regards,
Steffen

> 
> David
> 
> 
> Le 24/04/2026 à 09:27, Steffen Trumtrar a écrit :
> > On 2026-04-23 at 14:00 +02, David Picard <david.picard@clermont.in2p3.fr>
> > wrote:
> >
> > Hi,
> >
> >> Hello,
> >>
> >> @Stephen and Ian: I Cc you since I spotted you authored commits related to
> >> Intel
> >> SoC FPGA pin muxing.
> >>
> >
> > long time ago ;)
> >
> >> I'm trying to enable the I2C1 bus on a Cyclone V-base module, mounted on a
> >> base
> >> board. The I2C1 lines connect to a 2.54mm header, on which I attached a I²C
> >> device with pull-up resistors at address 0x40.
> >> https://www.enclustra.com/en/products/system-on-chip-modules/mercury-sa2/ I
> >> can't detect the I²C device, nor can I see any pulse on the SCL line, which
> >> is
> >> constantly at +3.3V.
> >>
> >> I changed the pin muxing in Quartus, updated the handoff files, changed the
> >> devicetree. The I2C1 bus is visible in Barebox and Linux. More detail here:
> >> https://community.altera.com/discussions/fpga-device/cyclone-v-hps-i2c1-issue-no-activity-on-bus/352583 
> >
> > I remember, that iocsr was 'underdocumented' to say the least...
> >
> > Wasn't it possible to change drive strength and those settings or was that
> > with Xilinx/Zynq?
> >
> >> As documented on the Barebox website, I generated the BSP files with the
> >> Quartus
> >> script bsp-create-settings and copied the handoff files to the Barebox build
> >> directory. After that, I could see that iocsr_config_cyclone5.c and
> >> pinmux_config.c had changed.
> >> https://www.barebox.org/doc/2025.05.0/boards/socfpga.html#updating-handoff-files
> >> https://www.intel.com/content/www/us/en/docs/programmable/683187/20-1/bsp-create-settings.html
> >> If someone could give me some hint, that would be really great!
> >
> > I see, that the Terasic DE10 Nano uses i2c1. Maybe compare the changed iocsr
> > with those?
> >
> >
> > Best regards,
> > Steffen
> >

-- 
Pengutronix e.K.                | Dipl.-Inform. Steffen Trumtrar |
Steuerwalder Str. 21            | https://www.pengutronix.de/    |
31137 Hildesheim, Germany       | Phone: +49-5121-206917-0       |
Amtsgericht Hildesheim, HRA 2686| Fax:   +49-5121-206917-5555    |

Re: ARM: socfpga: enclustra-sa2: issue with I2C1

[David Picard]

Too bad you don't have an idea. Sorry for misspelling your name,

I'm not sure it's related, but I get errors with the 
socfpga_import_preloader script only if I use the --embedded-sdk option. 
I couldn't figure out what this option changes.
https://paste.debian.net/hidden/fffbb190

David

Le 27/04/2026 à 12:20, Steffen Trumtrar a écrit :
> On 2026-04-27 at 12:09 +02, David Picard 
> <david.picard@clermont.in2p3.fr> wrote:
>
> Hi,
>
>> Hi Stephen, thanks for your reply,
>>
>> Pins SDA and SCL, GPIO51 and GPIO52 respectively, are specified with 
>> the I/O
>> standard 3.3V LVCMOS and a drive strength of 2mA, which is way more 
>> than needed,
>> given my 10K pull-up resistors (3.3 / 10K = 0.33mA). I know that 10K 
>> is bigger
>> than the usual 2.2K, but probably not big enough to prevent any 
>> change on the
>> SCL line. I just see a perfect flat line when I probe the bus.
>>
>
> :(
>
>> I compared iocsr_config_cyclone5.c and pinmux_config.c in the 
>> terasic-de10-nano/
>> and enclustra-sa2/ directories. There are a lot of differences. But 
>> the lines
>> that changed in enclustra-sa2/ when I tried to enable the I2C1 bus 
>> are now the
>> same as in the terasic-de10-nano/ directory, which probably makes sense.
>>
>
> Makes sence, yes and was what I hoped for. But, doesn't seem to change 
> anything.
>
>> Does Barebox have to decipher every bit in those cryptic files?
>>
>
> barebox knows nothing about the meaning of the iocsr registers. Those 
> values a just written to the hardware and can't be changed afterwards.
> AFAIK there still is no linux driver that might read and decipher the 
> settings.
>
> Sadly, I don't have any more ideas at the top of my head why it 
> doesn't work. Everything sounds correct.
>
>
> Best regards,
> Steffen
>
>>
>> David
>>
>>
>> Le 24/04/2026 à 09:27, Steffen Trumtrar a écrit :
>> > On 2026-04-23 at 14:00 +02, David Picard 
>> <david.picard@clermont.in2p3.fr>
>> > wrote:
>> >
>> > Hi,
>> >
>> >> Hello,
>> >>
>> >> @Stephen and Ian: I Cc you since I spotted you authored commits 
>> related to
>> >> Intel
>> >> SoC FPGA pin muxing.
>> >>
>> >
>> > long time ago ;)
>> >
>> >> I'm trying to enable the I2C1 bus on a Cyclone V-base module, 
>> mounted on a
>> >> base
>> >> board. The I2C1 lines connect to a 2.54mm header, on which I 
>> attached a I²C
>> >> device with pull-up resistors at address 0x40.
>> >> 
>> https://www.enclustra.com/en/products/system-on-chip-modules/mercury-sa2/ 
>> I
>> >> can't detect the I²C device, nor can I see any pulse on the SCL 
>> line, which
>> >> is
>> >> constantly at +3.3V.
>> >>
>> >> I changed the pin muxing in Quartus, updated the handoff files, 
>> changed the
>> >> devicetree. The I2C1 bus is visible in Barebox and Linux. More 
>> detail here:
>> >> 
>> https://community.altera.com/discussions/fpga-device/cyclone-v-hps-i2c1-issue-no-activity-on-bus/352583 
>> >
>> > I remember, that iocsr was 'underdocumented' to say the least...
>> >
>> > Wasn't it possible to change drive strength and those settings or 
>> was that
>> > with Xilinx/Zynq?
>> >
>> >> As documented on the Barebox website, I generated the BSP files 
>> with the
>> >> Quartus
>> >> script bsp-create-settings and copied the handoff files to the 
>> Barebox build
>> >> directory. After that, I could see that iocsr_config_cyclone5.c and
>> >> pinmux_config.c had changed.
>> >> 
>> https://www.barebox.org/doc/2025.05.0/boards/socfpga.html#updating-handoff-files
>> >> 
>> https://www.intel.com/content/www/us/en/docs/programmable/683187/20-1/bsp-create-settings.html
>> >> If someone could give me some hint, that would be really great!
>> >
>> > I see, that the Terasic DE10 Nano uses i2c1. Maybe compare the 
>> changed iocsr
>> > with those?
>> >
>> >
>> > Best regards,
>> > Steffen
>> >
>

Re: ARM: socfpga: enclustra-sa2: issue with I2C1

[Steffen Trumtrar]

On 2026-04-27 at 14:13 +02, David Picard <david.picard@clermont.in2p3.fr> wrote:

> Too bad you don't have an idea. Sorry for misspelling your name,
>

no problem ;)

> 
> I'm not sure it's related, but I get errors with the socfpga_import_preloader
> script only if I use the --embedded-sdk option. I couldn't figure out what this
> option changes.
> https://paste.debian.net/hidden/fffbb190
>

Hm, the script is obviously pretty hacked together and not very error proof.
With the embedded-sdk provided, it generates the handoff-files without the
option, the handoff files need to be generated manually.

Maybe the Python script in the SDK changed since adding this option and doesn't
copy the files that are stat'ed.


Steffen

> David
> 
> Le 27/04/2026 à 12:20, Steffen Trumtrar a écrit :
> > On 2026-04-27 at 12:09 +02, David Picard <david.picard@clermont.in2p3.fr>
> > wrote:
> >
> > Hi,
> >
> >> Hi Stephen, thanks for your reply,
> >>
> >> Pins SDA and SCL, GPIO51 and GPIO52 respectively, are specified with the I/O
> >> standard 3.3V LVCMOS and a drive strength of 2mA, which is way more than
> >> needed,
> >> given my 10K pull-up resistors (3.3 / 10K = 0.33mA). I know that 10K is
> >> bigger
> >> than the usual 2.2K, but probably not big enough to prevent any change on the
> >> SCL line. I just see a perfect flat line when I probe the bus.
> >>
> >
> > :(
> >
> >> I compared iocsr_config_cyclone5.c and pinmux_config.c in the
> >> terasic-de10-nano/
> >> and enclustra-sa2/ directories. There are a lot of differences. But the lines
> >> that changed in enclustra-sa2/ when I tried to enable the I2C1 bus are now
> >> the
> >> same as in the terasic-de10-nano/ directory, which probably makes sense.
> >>
> >
> > Makes sence, yes and was what I hoped for. But, doesn't seem to change
> > anything.
> >
> >> Does Barebox have to decipher every bit in those cryptic files?
> >>
> >
> > barebox knows nothing about the meaning of the iocsr registers. Those values a
> > just written to the hardware and can't be changed afterwards.
> > AFAIK there still is no linux driver that might read and decipher the
> > settings.
> >
> > Sadly, I don't have any more ideas at the top of my head why it doesn't work.
> > Everything sounds correct.
> >
> >
> > Best regards,
> > Steffen
> >
> >>
> >> David
> >>
> >>
> >> Le 24/04/2026 à 09:27, Steffen Trumtrar a écrit :
> >> > On 2026-04-23 at 14:00 +02, David Picard <david.picard@clermont.in2p3.fr>
> >> > wrote:
> >> >
> >> > Hi,
> >> >
> >> >> Hello,
> >> >>
> >> >> @Stephen and Ian: I Cc you since I spotted you authored commits related to
> >> >> Intel
> >> >> SoC FPGA pin muxing.
> >> >>
> >> >
> >> > long time ago ;)
> >> >
> >> >> I'm trying to enable the I2C1 bus on a Cyclone V-base module, mounted on a
> >> >> base
> >> >> board. The I2C1 lines connect to a 2.54mm header, on which I attached a
> >> I²C
> >> >> device with pull-up resistors at address 0x40.
> >> >> https://www.enclustra.com/en/products/system-on-chip-modules/mercury-sa2/
> >> I
> >> >> can't detect the I²C device, nor can I see any pulse on the SCL line,
> >> which
> >> >> is
> >> >> constantly at +3.3V.
> >> >>
> >> >> I changed the pin muxing in Quartus, updated the handoff files, changed
> >> the
> >> >> devicetree. The I2C1 bus is visible in Barebox and Linux. More detail
> >> here:
> >> >>
> >> https://community.altera.com/discussions/fpga-device/cyclone-v-hps-i2c1-issue-no-activity-on-bus/352583
> >> >
> >> > I remember, that iocsr was 'underdocumented' to say the least...
> >> >
> >> > Wasn't it possible to change drive strength and those settings or was that
> >> > with Xilinx/Zynq?
> >> >
> >> >> As documented on the Barebox website, I generated the BSP files with the
> >> >> Quartus
> >> >> script bsp-create-settings and copied the handoff files to the Barebox
> >> build
> >> >> directory. After that, I could see that iocsr_config_cyclone5.c and
> >> >> pinmux_config.c had changed.
> >> >>
> >> https://www.barebox.org/doc/2025.05.0/boards/socfpga.html#updating-handoff-files
> >> >>
> >> https://www.intel.com/content/www/us/en/docs/programmable/683187/20-1/bsp-create-settings.html
> >> >> If someone could give me some hint, that would be really great!
> >> >
> >> > I see, that the Terasic DE10 Nano uses i2c1. Maybe compare the changed
> >> iocsr
> >> > with those?
> >> >
> >> >
> >> > Best regards,
> >> > Steffen
> >> >
> >

-- 
Pengutronix e.K.                | Dipl.-Inform. Steffen Trumtrar |
Steuerwalder Str. 21            | https://www.pengutronix.de/    |
31137 Hildesheim, Germany       | Phone: +49-5121-206917-0       |
Amtsgericht Hildesheim, HRA 2686| Fax:   +49-5121-206917-5555    |

Re: ARM: socfpga: enclustra-sa2: issue with I2C1

[David Picard]

Generate the handoff files manually: is it what the bsp-create-settings 
script from Intel's embedded shell does? I did run it.

I understand that socfpga_import_preloader mostly only reformats the files.


Le 27/04/2026 à 14:25, Steffen Trumtrar a écrit :
> On 2026-04-27 at 14:13 +02, David Picard 
> <david.picard@clermont.in2p3.fr> wrote:
>
>> Too bad you don't have an idea. Sorry for misspelling your name,
>>
>
> no problem ;)
>
>>
>> I'm not sure it's related, but I get errors with the 
>> socfpga_import_preloader
>> script only if I use the --embedded-sdk option. I couldn't figure out 
>> what this
>> option changes.
>> https://paste.debian.net/hidden/fffbb190
>>
>
> Hm, the script is obviously pretty hacked together and not very error 
> proof.
> With the embedded-sdk provided, it generates the handoff-files without 
> the
> option, the handoff files need to be generated manually.
>
> Maybe the Python script in the SDK changed since adding this option 
> and doesn't
> copy the files that are stat'ed.
>
>
> Steffen
>
>> David
>>
>> Le 27/04/2026 à 12:20, Steffen Trumtrar a écrit :
>> > On 2026-04-27 at 12:09 +02, David Picard 
>> <david.picard@clermont.in2p3.fr>
>> > wrote:
>> >
>> > Hi,
>> >
>> >> Hi Stephen, thanks for your reply,
>> >>
>> >> Pins SDA and SCL, GPIO51 and GPIO52 respectively, are specified 
>> with the I/O
>> >> standard 3.3V LVCMOS and a drive strength of 2mA, which is way 
>> more than
>> >> needed,
>> >> given my 10K pull-up resistors (3.3 / 10K = 0.33mA). I know that 
>> 10K is
>> >> bigger
>> >> than the usual 2.2K, but probably not big enough to prevent any 
>> change on the
>> >> SCL line. I just see a perfect flat line when I probe the bus.
>> >>
>> >
>> > :(
>> >
>> >> I compared iocsr_config_cyclone5.c and pinmux_config.c in the
>> >> terasic-de10-nano/
>> >> and enclustra-sa2/ directories. There are a lot of differences. 
>> But the lines
>> >> that changed in enclustra-sa2/ when I tried to enable the I2C1 bus 
>> are now
>> >> the
>> >> same as in the terasic-de10-nano/ directory, which probably makes 
>> sense.
>> >>
>> >
>> > Makes sence, yes and was what I hoped for. But, doesn't seem to change
>> > anything.
>> >
>> >> Does Barebox have to decipher every bit in those cryptic files?
>> >>
>> >
>> > barebox knows nothing about the meaning of the iocsr registers. 
>> Those values a
>> > just written to the hardware and can't be changed afterwards.
>> > AFAIK there still is no linux driver that might read and decipher the
>> > settings.
>> >
>> > Sadly, I don't have any more ideas at the top of my head why it 
>> doesn't work.
>> > Everything sounds correct.
>> >
>> >
>> > Best regards,
>> > Steffen
>> >
>> >>
>> >> David
>> >>
>> >>
>> >> Le 24/04/2026 à 09:27, Steffen Trumtrar a écrit :
>> >> > On 2026-04-23 at 14:00 +02, David Picard 
>> <david.picard@clermont.in2p3.fr>
>> >> > wrote:
>> >> >
>> >> > Hi,
>> >> >
>> >> >> Hello,
>> >> >>
>> >> >> @Stephen and Ian: I Cc you since I spotted you authored commits 
>> related to
>> >> >> Intel
>> >> >> SoC FPGA pin muxing.
>> >> >>
>> >> >
>> >> > long time ago ;)
>> >> >
>> >> >> I'm trying to enable the I2C1 bus on a Cyclone V-base module, 
>> mounted on a
>> >> >> base
>> >> >> board. The I2C1 lines connect to a 2.54mm header, on which I 
>> attached a
>> >> I²C
>> >> >> device with pull-up resistors at address 0x40.
>> >> >> 
>> https://www.enclustra.com/en/products/system-on-chip-modules/mercury-sa2/
>> >> I
>> >> >> can't detect the I²C device, nor can I see any pulse on the SCL 
>> line,
>> >> which
>> >> >> is
>> >> >> constantly at +3.3V.
>> >> >>
>> >> >> I changed the pin muxing in Quartus, updated the handoff files, 
>> changed
>> >> the
>> >> >> devicetree. The I2C1 bus is visible in Barebox and Linux. More 
>> detail
>> >> here:
>> >> >>
>> >> 
>> https://community.altera.com/discussions/fpga-device/cyclone-v-hps-i2c1-issue-no-activity-on-bus/352583
>> >> >
>> >> > I remember, that iocsr was 'underdocumented' to say the least...
>> >> >
>> >> > Wasn't it possible to change drive strength and those settings 
>> or was that
>> >> > with Xilinx/Zynq?
>> >> >
>> >> >> As documented on the Barebox website, I generated the BSP files 
>> with the
>> >> >> Quartus
>> >> >> script bsp-create-settings and copied the handoff files to the 
>> Barebox
>> >> build
>> >> >> directory. After that, I could see that iocsr_config_cyclone5.c 
>> and
>> >> >> pinmux_config.c had changed.
>> >> >>
>> >> 
>> https://www.barebox.org/doc/2025.05.0/boards/socfpga.html#updating-handoff-files
>> >> >>
>> >> 
>> https://www.intel.com/content/www/us/en/docs/programmable/683187/20-1/bsp-create-settings.html
>> >> >> If someone could give me some hint, that would be really great!
>> >> >
>> >> > I see, that the Terasic DE10 Nano uses i2c1. Maybe compare the 
>> changed
>> >> iocsr
>> >> > with those?
>> >> >
>> >> >
>> >> > Best regards,
>> >> > Steffen
>> >> >
>> >
>

Re: ARM: socfpga: enclustra-sa2: issue with I2C1

[David Picard]

Hi,

I don't know exactly why and how, but after re-doing everything multiple 
times, it finally worked!

Anyway, I have a new version of the handoff files with I2C1 enabled on 2 
HPS pins. Is it worth sharing with Barebox, or is it too specific?

Next, I'll try to enable a SPI master. Same question.


David



Le 27/04/2026 à 14:36, David Picard a écrit :
> Generate the handoff files manually: is it what the 
> bsp-create-settings script from Intel's embedded shell does? I did run 
> it.
>
> I understand that socfpga_import_preloader mostly only reformats the 
> files.
>
>
> Le 27/04/2026 à 14:25, Steffen Trumtrar a écrit :
>> On 2026-04-27 at 14:13 +02, David Picard 
>> <david.picard@clermont.in2p3.fr> wrote:
>>
>>> Too bad you don't have an idea. Sorry for misspelling your name,
>>>
>>
>> no problem ;)
>>
>>>
>>> I'm not sure it's related, but I get errors with the 
>>> socfpga_import_preloader
>>> script only if I use the --embedded-sdk option. I couldn't figure 
>>> out what this
>>> option changes.
>>> https://paste.debian.net/hidden/fffbb190
>>>
>>
>> Hm, the script is obviously pretty hacked together and not very error 
>> proof.
>> With the embedded-sdk provided, it generates the handoff-files 
>> without the
>> option, the handoff files need to be generated manually.
>>
>> Maybe the Python script in the SDK changed since adding this option 
>> and doesn't
>> copy the files that are stat'ed.
>>
>>
>> Steffen
>>
>>> David
>>>
>>> Le 27/04/2026 à 12:20, Steffen Trumtrar a écrit :
>>> > On 2026-04-27 at 12:09 +02, David Picard 
>>> <david.picard@clermont.in2p3.fr>
>>> > wrote:
>>> >
>>> > Hi,
>>> >
>>> >> Hi Stephen, thanks for your reply,
>>> >>
>>> >> Pins SDA and SCL, GPIO51 and GPIO52 respectively, are specified 
>>> with the I/O
>>> >> standard 3.3V LVCMOS and a drive strength of 2mA, which is way 
>>> more than
>>> >> needed,
>>> >> given my 10K pull-up resistors (3.3 / 10K = 0.33mA). I know that 
>>> 10K is
>>> >> bigger
>>> >> than the usual 2.2K, but probably not big enough to prevent any 
>>> change on the
>>> >> SCL line. I just see a perfect flat line when I probe the bus.
>>> >>
>>> >
>>> > :(
>>> >
>>> >> I compared iocsr_config_cyclone5.c and pinmux_config.c in the
>>> >> terasic-de10-nano/
>>> >> and enclustra-sa2/ directories. There are a lot of differences. 
>>> But the lines
>>> >> that changed in enclustra-sa2/ when I tried to enable the I2C1 
>>> bus are now
>>> >> the
>>> >> same as in the terasic-de10-nano/ directory, which probably makes 
>>> sense.
>>> >>
>>> >
>>> > Makes sence, yes and was what I hoped for. But, doesn't seem to 
>>> change
>>> > anything.
>>> >
>>> >> Does Barebox have to decipher every bit in those cryptic files?
>>> >>
>>> >
>>> > barebox knows nothing about the meaning of the iocsr registers. 
>>> Those values a
>>> > just written to the hardware and can't be changed afterwards.
>>> > AFAIK there still is no linux driver that might read and decipher the
>>> > settings.
>>> >
>>> > Sadly, I don't have any more ideas at the top of my head why it 
>>> doesn't work.
>>> > Everything sounds correct.
>>> >
>>> >
>>> > Best regards,
>>> > Steffen
>>> >
>>> >>
>>> >> David
>>> >>
>>> >>
>>> >> Le 24/04/2026 à 09:27, Steffen Trumtrar a écrit :
>>> >> > On 2026-04-23 at 14:00 +02, David Picard 
>>> <david.picard@clermont.in2p3.fr>
>>> >> > wrote:
>>> >> >
>>> >> > Hi,
>>> >> >
>>> >> >> Hello,
>>> >> >>
>>> >> >> @Stephen and Ian: I Cc you since I spotted you authored 
>>> commits related to
>>> >> >> Intel
>>> >> >> SoC FPGA pin muxing.
>>> >> >>
>>> >> >
>>> >> > long time ago ;)
>>> >> >
>>> >> >> I'm trying to enable the I2C1 bus on a Cyclone V-base module, 
>>> mounted on a
>>> >> >> base
>>> >> >> board. The I2C1 lines connect to a 2.54mm header, on which I 
>>> attached a
>>> >> I²C
>>> >> >> device with pull-up resistors at address 0x40.
>>> >> >> 
>>> https://www.enclustra.com/en/products/system-on-chip-modules/mercury-sa2/
>>> >> I
>>> >> >> can't detect the I²C device, nor can I see any pulse on the 
>>> SCL line,
>>> >> which
>>> >> >> is
>>> >> >> constantly at +3.3V.
>>> >> >>
>>> >> >> I changed the pin muxing in Quartus, updated the handoff 
>>> files, changed
>>> >> the
>>> >> >> devicetree. The I2C1 bus is visible in Barebox and Linux. More 
>>> detail
>>> >> here:
>>> >> >>
>>> >> 
>>> https://community.altera.com/discussions/fpga-device/cyclone-v-hps-i2c1-issue-no-activity-on-bus/352583
>>> >> >
>>> >> > I remember, that iocsr was 'underdocumented' to say the least...
>>> >> >
>>> >> > Wasn't it possible to change drive strength and those settings 
>>> or was that
>>> >> > with Xilinx/Zynq?
>>> >> >
>>> >> >> As documented on the Barebox website, I generated the BSP 
>>> files with the
>>> >> >> Quartus
>>> >> >> script bsp-create-settings and copied the handoff files to the 
>>> Barebox
>>> >> build
>>> >> >> directory. After that, I could see that 
>>> iocsr_config_cyclone5.c and
>>> >> >> pinmux_config.c had changed.
>>> >> >>
>>> >> 
>>> https://www.barebox.org/doc/2025.05.0/boards/socfpga.html#updating-handoff-files
>>> >> >>
>>> >> 
>>> https://www.intel.com/content/www/us/en/docs/programmable/683187/20-1/bsp-create-settings.html
>>> >> >> If someone could give me some hint, that would be really great!
>>> >> >
>>> >> > I see, that the Terasic DE10 Nano uses i2c1. Maybe compare the 
>>> changed
>>> >> iocsr
>>> >> > with those?
>>> >> >
>>> >> >
>>> >> > Best regards,
>>> >> > Steffen
>>> >> >
>>> >
>>
>
>