Forum Discussion
Occasional Contributordriver for HPS I2C Hardware in u-boot 04.2020 deactivates clocks
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
New ContributorWe have experienced this as well.
You have tracked the problem down correctly to DM_REMOVE_ACTIVE_ALL.
The problem is that uboot Device Model will try to deactivate the i2c device node, taking down the associated l4_sp_clk with it. There is probably a proper fix for this problem, however doing the following is a workaround:
1. Create a virtual fixed-clock in your uboot dts file. Something like this:
clk_virt_l4_sp: clk_virt_l4_sp {
#clock-cells = <0>;
compatible = "fixed-clock";
clock-frequency = <100000000>;
};
The frequency (100MHz here) has to match your FPGA design (check your HPS clock configuration in qsys..).
2.
Re-assign the clock of the i2c node you are using to the new virtual fixed clock. Something like this, when done in a dts or dtsi file which includes the main dtsi file (where i2c0 is defined):
&i2c0 {
clocks = <&clk_virt_l4_sp>;
}
With this workaround, uboot will not try to deactivate l4_sp_clk before starting the linux kernel and it should boot fine.
Hope it helps.
Hussein Alasadi
ARECS GmbH
Occasional ContributorHi Hussein,
Many thanks for your answer. For me it make sens, that a "fixed-clock" is a workaround to solve this issue. In a first step, I try to implement this on in the device tree for the development board (right now in u-boot 2020.10).
I added the clk_virt_l4_sp node in the clock section of the device tree where also the other fixed clocks (osc1, f2s_free_clk, ...) are. For your interest I put the updated socfpga_arria10.dtsi (renamed to *.txt) file in the attach.
Now I see an issue when loading the i2c driver. It seams, that no clock frequency is given by the instantiated clock node. One debug output from the driver is: dw_i2c: mode 0, ic_clk 0, speed 100000, period 0 rise 0 fall 0 tlow 0 thigh 0 spk 0 which shows, that the clock frequency is 0.
I think, maybe I put the clk_virt_l4_sp definition in the wrong location in the device tree? Do you know the correct location of it?
Thanks and best regards,
Silvan
