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

[David Picard <david.picard@clermont.in2p3.fr>]

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