mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: David Picard <david.picard@clermont.in2p3.fr>
To: Steffen Trumtrar <s.trumtrar@pengutronix.de>
Cc: ML_Barebox <barebox@lists.infradead.org>, abbotti@mev.co.uk
Subject: Re: ARM: socfpga: enclustra-sa2: issue with I2C1
Date: Mon, 27 Apr 2026 14:36:18 +0200	[thread overview]
Message-ID: <0d87b14c-4696-46e1-bf37-6bbfa0f24b8d@clermont.in2p3.fr> (raw)
In-Reply-To: <87pl3ktwsq.fsf@pengutronix.de>

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




      reply	other threads:[~2026-04-27 12:36 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-23 12:00 David Picard
2026-04-24  7:27 ` Steffen Trumtrar
2026-04-27 10:09   ` David Picard
2026-04-27 10:20     ` Steffen Trumtrar
2026-04-27 12:13       ` David Picard
2026-04-27 12:25         ` Steffen Trumtrar
2026-04-27 12:36           ` David Picard [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0d87b14c-4696-46e1-bf37-6bbfa0f24b8d@clermont.in2p3.fr \
    --to=david.picard@clermont.in2p3.fr \
    --cc=abbotti@mev.co.uk \
    --cc=barebox@lists.infradead.org \
    --cc=s.trumtrar@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox