• State TI Thinks Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 101 subscribers
  • Views 3034 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

FIXME fck errors during Linux boot

Andy Pont
Intellectual 380 points

Other Parts Discussed in Thread: TPS65217, AM3354

During the early stages of the boot process for the Linux 3.12.10 kernel I noted the following three messages relating to clock definitions missing from the device tree.

[ 0.226040] platform mpu.1: FIXME: clock-name 'fck' DOES NOT exist in dt!
[ 0.234376] platform 49000000.edma: FIXME: clock-name 'fck' DOES NOT exist in dt!
[ 0.258717] platform 56000000.sgx: FIXME: clock-name 'fck' DOES NOT exist in dt!

Does anyone have the necessary information to correct them?

Thanks,

Andy.

  • 0
    TI__Guru**** 393215 points

    Hi Andy,

    I will forward this to the SW team, but please provide more details about hardware used.

  • 0 in reply to Biser Gatchev-XID
    TI__Expert 4475 points
    Hi Andy,

    For the "[ 0.226040] platform mpu.1: FIXME: clock-name 'fck' DOES NOT exist in dt!" is dpll_mpu_m2_ck. This is a clock divider and if you want can calculate the divider value. You can see in the TRM 8.1.6.8.1 Configuring the MPU PLL.
    For the "[ 0.234376] platform 49000000.edma: FIXME: clock-name 'fck' DOES NOT exist in dt!" is l3_gclk. This clock is initialized on next entry in a such procedure..
    For the "[ 0.258717] platform 56000000.sgx: FIXME: clock-name 'fck' DOES NOT exist in dt!" is gfx_fck_div_ck. This is also clock divider and you can see int the TRM 8.1.12.3.10 CLKSEL_GFX_FCLK its value. For more information if you want see from the TRM 8.1.12.7 CM_GFX Registers and "Selects the divider value for GFX clock".

    If you want to initialize in a dt file, the correct place is in am33xx.dtsi file.

    BR
    Ivan
  • 0 in reply to Biser Gatchev-XID
    Intellectual 380 points
    The board is a custom platform based on the AM3354 with a TPS65217 and 24MHz crystal oscilator. What other information do you need?

    Andy.
  • 0 in reply to Ivan Matrakov
    Intellectual 680 points
    Ivan,

    Do you have how this would be resolved in the am33xx.dtsi file?
  • 0 in reply to Peter M
    Intellectual 680 points
    We are using th 7.0 SDK and the kernel that came with it. Kernel 3.12.10
  • 0 in reply to Peter M
    TI__Guru**** 161600 points
    Hi,

    In general clocks are located in am33xx-clocks.dtsi. So you should track which clock is not initializing.

    However usually this is related to erroneous settings in the module dts node, which uses the reported bad clock.

    Can you post your bootlog? Also your .dts file?

    Best Regards,
    Yordan
  • 0 in reply to Yordan Kovachev
    TI__Guru*** 125430 points
    I was comparing with the most recent. I'm wondering if the graphics clock error might be solved like this:

    diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
    index 2b66e67..5e2acac 100644
    --- a/arch/arm/boot/dts/am33xx.dtsi
    +++ b/arch/arm/boot/dts/am33xx.dtsi
    @@ -856,6 +856,8 @@
    ti,hwmods = "gfx";
    reg = <0x56000000 0x1000000>;
    interrupts = <37>;
    + clocks = <&gfx_fck_div_ck>;
    + clock-names = "fclk";
    resets = <&prcm 0>;
    };
  • 0 in reply to Brad Griffis
    Intellectual 680 points
    HI Brad,
    I will update and let you know.

    Peter M.
  • 0 in reply to Peter M
    Intellectual 680 points
    Hey Brad,

    Bit of change from you update.
    + clock-names = "fclk";
    should be
    + clock-names = "fck";

    Also, based on Ivan suggest approve and to solve the other 2 ('fck' DOES NOT exist in dt!") , I added (see - +) the following in same file (am33xx.dtsi).

    soc {
    compatible = "ti,omap-infra";
    mpu {
    compatible = "ti,omap5-mpu";
    ti,hwmods = "mpu";
    +clocks = <&dpll_mpu_m2_ck>;
    +clock-names = "fck";
    };


    edma: edma@49000000 {
    compatible = "ti,edma3";
    ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
    reg = <0x49000000 0x10000>,
    <0x44e10f90 0x10>;
    interrupts = <12 13 14>;
    #dma-cells = <1>;
    dma-channels = <64>;
    ti,edma-regions = <4>;
    ti,edma-slots = <256>;
    +clocks = <&l3_gclk>;
    +clock-names = "fck";
    };

    Please doube check my update and let me if there would be an issue with it.

    Thanks
  • 0 in reply to Peter M
    TI__Guru*** 125430 points

    I tried it out on my EVM.  I took the binaries from SDK 7.00 as a starting point and checked through all the clocks, including the use of JTAG to grab a clock tree dump as described here:

    http://processors.wiki.ti.com/index.php/AM335x_Clock_Tree_Tool#Importing_Data_from_Actual_Hardware

    I then applied the changes you mentioned and captured new logs for comparison.  I can confirm that fixes the warnings.  Furthermore, it changes absolutely nothing in the way the device is being clocked, so I think it's safe to conclude that these were harmless messages in the first place.  However, yes, to fix them your changes are correct.  Here are the logs I took in case you're interested: 4745.files.zip