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