Forum Discussion

Silvan's avatar
Silvan
Icon for Occasional Contributor rankOccasional Contributor
6 years ago
Solved

driver for HPS I2C Hardware in u-boot 04.2020 deactivates clocks

Hello all, I have an Arria 10 SoC device on our custom board. The board boots from an SD Card, loading u-boot and than a Linux kernel. Until now, I used an old u-boot build flow utilized Quartus an...
  • MWill5's avatar
    MWill5
    5 years ago

    Hello,

    We had a similar problem trying to migrate to the socfpga_v2021.04 branch of uBoot. We have an on-board EEPROM (I2C) that contains factory configuration data that is needed during the uBoot TPL phase.

    We are seeing that the designware_i2c I2C controller is resetting the l4_sp_clk when it is removed prior to starting the linux kernel. The result is that there is a bus hang when the kernel tries to access the UART peripheral (which needs that clock). The kernel we are trying to use is from 4.9.78-ltsi. It's possible that later versions of the kernel properly re-enable the l4_sp_clk, but this doesn't seem to be the case for our particular configuration (which works fine with uboot 2014.10). We also had to set the socfpga_legacy_reset_compat=1 uBoot environment variable as well, as without it this version of uBoot will reset all the peripherals as it switches to linux, resulting in a similar hang.

    Our work-around can be found in this patch here:

    Critical Link LLC git repositories. - u-boot-socfpga.git/blobdiff - drivers/i2c/designware_i2c.c

    -Mike

EBERLAZARE_I_Intel's avatar
EBERLAZARE_I_Intel
Icon for Regular Contributor rankRegular Contributor
5 years ago

Hi Silvan,

I noticed that you changed from the default configuration, thus you may need to change the Linux's device tree as well, you may find in similar directory:

\linux-socfpga-socfpga-5.4.54-lts\arch\arm\boot\dts

The file is called "socfpga_arria10_socdk".

From my experience of changing Uboot settings for a custom board, if you opt to use the Linux, you need to check the Linux's device tree as well. In addition, before changing the device tree, you need to check if the other config of the I2C is reliable to what you looking for, the frequency, compatible, etc..

Also, are you using "I2C1" in the old Uboot that worked?

Silvan's avatar
Silvan
Icon for Occasional Contributor rankOccasional Contributor
5 years ago

Hi Eberlazare,

Thanks for your feedback.

I didn’t changed the Linux device tree during the u-boot migration from 2014.10 to 2020.04. Is it required? I think the issue which I observe in u-boot 2020.04 is shortly before the Linux kernel starts.

Our u-boot device tree is based on \arch\arm\dts\socfpga_arria10.dtsi which includes the I2C1 device information (compatible, clock, ...). I think, its configuration is correct because I’m able to communicate with our EEPROM from u-boot.

The issue which I’m observe is when u-boot switch to the Linux kernel. Before loading the kernel, u-boot has a clean-up routine to release allocated hardware resources. And at the point when the enabled I2C hardware is released, the system stops to work. I added additional debug/print-outputs in the u-boot sources to isolate the issue. I attached the log on this reply and a description follows bellow.

Yes, the old u-boot version 2014.10 used also I2C1 to read the MAC address from an external EEPROM. As far as I understand, the Hardware and FPGA firmware work correctly. So what is the recommendation to enable and use the I2C hardware in u-boot 2020.04? Is it wrong to just enable the i2c hardware based on \arch\arm\dts\socfpga_arria10.dtsi?

Short log description:

  1. Enabling the I2C device with ‘i2c dev 0’ (Line 44) and list available devices with ‘i2c prob’ (Line 52).
  2. Boot Linux kernel with ‘run bootcmd’ (Line 54)
  3. Starting log in file: \arch\arm\lib\bootm.c In function ‘announce_and_cleanup(int fake)’ dm_remove_devices_flags(DM_REMOVE_ACTIVE_ALL); is called. (Line 87)
  4. The function is implemented in \drivers\core\root.c and calls ‘device_remove’ from \drivers\core\device-remove.c which loops over all active devices and disable it and there child. (Line 88)
  5. If I2C active (which is true after calling ‘i2c prob’) (Line 305) the remove function ‘designware_i2c_remove(struct udevice *dev)’ in /drivers/i2c/designware_i2c.c is called (Line 337). This function stops the l4_sp_clkclk_disable clock which results in a non working system and after a while the watchdog reboot the device… (Line 339)

  • EBERLAZARE_I_Intel's avatar
    EBERLAZARE_I_Intel
    Icon for Regular Contributor rankRegular Contributor
    5 years ago

    Hi,

    Yes as per my experience, it is required as you are running in Linux.

    Correct me if I am wrong, you did change in the Uboot device tree, and in Uboot you are not seeing such issue, but only in Linux am I correct?

    Have you tried changing the Linux device tree as well?

    • Silvan's avatar
      Silvan
      Icon for Occasional Contributor rankOccasional Contributor
      5 years ago

      Hi Eberlazare,

      No your assumption is wrong. I see such issue in Uboot! So I changed the Uboot device tree and using the I2C hardware in Uboot.

      After that, I'm not able to boot an Linux because Uboot never try to load and start the Linux as described in my previous post.

      Did you has any idea for that issue? And what is the recommendation from intel to using the I2C hardware in Uboot?

      • EBERLAZARE_I_Intel's avatar
        EBERLAZARE_I_Intel
        Icon for Regular Contributor rankRegular Contributor
        5 years ago

        Hi,

        My recommendation is to check with default settings of GHRD and UBoot.

        According to 2020.04 the device tree settings are set as per below:

        &i2c1 {
        status = "okay";

        /*
        * adjust the falling times to decrease the i2c frequency to 50Khz
        * because the LCD module does not work at the standard 100Khz
        */
        clock-frequency = <100000>;
        i2c-sda-falling-time-ns = <6000>;
        i2c-scl-falling-time-ns = <6000>;

        adc@14 {
        compatible = "lltc,ltc2497";
        reg = <0x14>;
        vref-supply = <&ref_033v>;
        };

        adc@16 {
        compatible = "lltc,ltc2497";
        reg = <0x16>;
        vref-supply = <&ref_033v>;
        };

        eeprom@51 {
        compatible = "atmel,24c32";
        reg = <0x51>;
        pagesize = <32>;
        };

        rtc@68 {
        compatible = "dallas,ds1339";
        reg = <0x68>;
        };

        ltc@5c {
        compatible = "ltc2977";
        reg = <0x5c>;
        };
        };

        The difference is the EEPROM part and also you did not specify the SDA and SCL falling time. I am unsure if adding the falling time would prevent the clock to be deactivated but it is worth a try.