• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 101 subscribers
  • Views 466 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.

Linux/AM5728: Disabling resources

Daniel Castagnola Weckesser
Intellectual 410 points

Part Number: AM5728

Tool/software: Linux

I need to free some resources currently attached to Linux in order to manage them from SYBIOS running on a DSP.

(BTW, these resources are some GPIO ports, one UART, one Ethernet, and one external FPGA connected through GPMC)

I understand that these changes must be performed in the device tree files, but have a cuple of doubts:

  1. Some devicetree files are duplicated in u-boot and kernel repos (and perhaps triplicated somewhere else in the SDK). So, which are the DT sources that we should touch up?
  2. Should we rebuild the entire kernel everytime the devicetree is modified, or would it be enough just to compile the dtb, move it to target, and reboot ?

Thanks in advance,

Daniel

  • 0
    TI__Guru**** 170625 points
    Hi Daniel,

    Refer to the below e2e thread:

    e2e.ti.com/.../698380

    Regards,
    Pavel
  • 0 in reply to Pavel Botev
    Intellectual 410 points

    Hi Pavel,

    Thank you very much for your prompt reply.

    I watched that thread but unfortunately there's no info related to the questions. I'll try to reformulate them more precisely here below:

    1) The SDK (v4.03) comes with two instances of the file "dra7.dts", in the following locations:

    /~/ti-processor-sdk-linux-am57xx-evm-04.03.00.05/board-support/linux-4.9.69+gitAUTOINC+9ce43c71ae-g9ce43c71ae/arch/arm/boot/dts/dra7.dtsi

    /~/ti-processor-sdk-linux-am57xx-evm-04.03.00.05/board-support/u-boot-2017.01+gitAUTOINC+c68ed086bd-gc68ed086bd/arch/arm/dts/dra7.dtsi

    I saw that both files have slightly different contents... which is the valid one to be compiled, and  what about the other ?

    2) Is it really neccessary to perform a full compilation after changing a device tree source, or just compiling the changed dts, updating the target with the resulting dtb, and rebooting the target would be enough ?   (please, have in mind the huge amount of time spent in every full kernel rebuild, so this is not so trivial) 

  • 0 in reply to Daniel Castagnola Weckesser
    TI__Guru*** 125430 points

    Daniel Castagnola Weckesser said:

    1) The SDK (v4.03) comes with two instances of the file "dra7.dts", in the following locations:

    /~/ti-processor-sdk-linux-am57xx-evm-04.03.00.05/board-support/linux-4.9.69+gitAUTOINC+9ce43c71ae-g9ce43c71ae/arch/arm/boot/dts/dra7.dtsi

    /~/ti-processor-sdk-linux-am57xx-evm-04.03.00.05/board-support/u-boot-2017.01+gitAUTOINC+c68ed086bd-gc68ed086bd/arch/arm/dts/dra7.dtsi

    I saw that both files have slightly different contents... which is the valid one to be compiled, and  what about the other ?

    Both are valid.  One is for u-boot and one is for Linux.  Given that u-boot drivers don't have the same capabilities as Linux drivers, I wouldn't expect them to be the same.  Generally speaking, I expect the Linux dts file to be the more important of the two given that u-boot is only running for a second or two at power-up.  Furthermore, the DSP's get loaded by Linux, so by that point in time you know with certainty that u-boot is no longer running.

    Daniel Castagnola Weckesser said:
    2) Is it really neccessary to perform a full compilation after changing a device tree source, or just compiling the changed dts, updating the target with the resulting dtb, and rebooting the target would be enough ?   (please, have in mind the huge amount of time spent in every full kernel rebuild, so this is not so trivial) 

    No.  This was precisely the driving force behind Linux (for ARM) moving to device tree.  It enables you to make board-level adjustments without having to rebuild the kernel.