• State TI Thinks Resolved
  • Locked Locked
  • Replies 16 replies
  • Answers 2 answers
  • Subscribers 99 subscribers
  • Views 1011 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: pinmux tool generated code application

Oleg Solovev
Expert 1985 points
Other Parts Discussed in Thread: AM5749, AM5748

Hello support!

I would like to know how to use pinmux tool.

I mean I wold like to add dcan2 for example.

1.You still didn't get am5749

2.I chose what I want for example:

3.Like I understood I should use some script for generating code from this files(genericFileFormatPadConf.txt and genericFileFormatPadConf.txt). I should get some file and integrate this code in mux_data.h

it is will be something for: const struct pad_conf_entry core_padconf_array_essential_am574x_idk and for const struct iodelay_cfg_entry iodelay_cfg_array_am574x_idk.

4.In devicetree.txt I will get code for Device tree obvious.

So which scrip I should use where I should get it?

I will try to download something but it doesn't generate code for 2 files.

BR,

Oleg

  • 0
    TI__Guru* 77774 points

    Hi Oleg,

    Apologies for a late response on this one.

    Oleg Solovev said:
    1.You still didn't get am5749

    You can use the AM5748 for this purpose.

    Oleg Solovev said:
    3.Like I understood I should use some script for generating code from this files(genericFileFormatPadConf.txt and genericFileFormatPadConf.txt). I should get some file and integrate this code in mux_data.h

    You can look at the devicetree.txt to for the pinmux and then add them to the mux_data.h

    Please find information on adding DCAN2 on AM5749 as below:

    So for dcan2 you can see the mux mode is 2.

    With that information please add the following in the pad_conf_entry core_padconf_array_essential_am574x_idk[] in u-boot/board/ti/am57xx/mux_data.h:

    {DCAN2_RX, (M2 | PIN_INPUT)},     /* gpio6_15.dcan2_rx */
{DCAN2_TX, (M2 | PIN_OUTPUT)},    /* gpio6_14.dcan2_tx */

    Please let me know if this doesn't work for you.

    Regards,

    Karan

  • 0 in reply to Karan Saxena
    Expert 1985 points

    Karan, You are great specialist  but I need more detail explanation.

    So...I chose Dcan2

    then look at the pins...

    we see MODE IS 16 FOR DCAN2

    Ok no problem look at the devicetree.txt

    The mux mode here it is 15 and 2....So I have a reasonable question what is wrong and how it is possible....

    Listen to me, I just want to understand how to use this tool correctly.

    I am completely sure that due to a misunderstanding of the principle of operation, I have problems with the periphery.

  • 0 in reply to Oleg Solovev
    TI__Guru* 77774 points

    Hi Oleg,

    I believe this is a bug in the pinmux tool - I have raised it up with the concerning team. I see values > 15 which is not possible. I will give you a confirmation when I hear back from them.

    To get the correct MUX MODE you can look at the datasheet - https://www.ti.com/lit/gpn/am5749 

    So for the dcan2_tx signal:

    In the pinmux tools output you can see it says gpio6_14.dcan2_tx. This means that the BALL NAME is gpio6_14 and it is muxed for dcan2_tx.

    The gpio6_14 corresponds to BALL NUMBER E21 and the MUX MODE for dcan2_tx is MUX MODE 2.

    So for the dcan2_rx signal:

    For dcan2_rx if you look at the datasheet you will see the below. It is MUXed at MUX MODE 2 for BALL gpio6_15 (F20). So it should have been MUX MODE 2 for this but the pinmux tool says errata i893.

    If you look this up in the errata document at https://www.ti.com/lit/pdf/sprz447 you will see:

    So the deviation from the data sheet on the MUX MODE is due to this errata.

    Oleg Solovev said:
    Listen to me, I just want to understand how to use this tool correctly.

    If all you are looking to do is understand how the tool works we can probably look at another example (which doesn't deviate from the data sheet due to any errata). If you want I can come up with an example explaining the process.

    Regards,

    Karan

  • 0 in reply to Karan Saxena
    Expert 1985 points

    Hi Karan,

    Karan I am newcomer and I thought it would be easy to do through pin mux tool...But now I see it is problem for me... It is realy looks like a bug.

    I just understand I should set pin mux mode 2 in mux_data.h

    1. Configure the DCAN module’s clock domain in SW_WKUP mode

    2.Configure CD_L4_CFG for NO_SLEEP mode

    3.Execute RAM Init Sequence

    I actually can't understand how and where exactly I should to do it. It should be configured in mux_data.h or in device tree ?

    Regards,

    Oleg

    If all you are looking to do is understand how the tool works we can probably look at another example (which doesn't deviate from the data sheet due to any errata). If you want I can come up with an example explaining the process.

    Yes Karan it will awesome ....

    Can I give you my mux_mode.h  and am574x-idk.dts for a check?

  • 0 in reply to Oleg Solovev
    TI__Guru* 77774 points

    Hi Oleg,

    Yes you can send me your mux_data.h.

    I will try to send you a patch on both u-boot (mux_data.h) and kernel (device tree) to enable this.

    Regards,

    Karan

  • 0 in reply to Karan Saxena
    Expert 1985 points

    Hi Karan,

    This is my files:

    My.zip

    Karan Like I said I would like to use DCAN2 and UART2 could you check both...I think I have the same problem with uart and If you change something please make a comments.

    Thx for help..

    BR,

    Oleg

  • 0 in reply to Oleg Solovev
    TI__Guru* 77774 points

    Hi Oleg,

    I do not have a AM57xx board with me so we might need to run some tests on you side.

    1. Are you able to validate the DCAN1 working? (with the default SDK, no changes to device tree or mux_data.h)

    This is important as then we can add DCAN2 in the same way as DCAN1 is added.

    2. There are two places where the PINMUX needs to happen. Based on the result of 1. we can proceed here.

    These things are important as the DCAN has the errata that I pointed you to.

    Regards,

    Karan

  • 0 in reply to Karan Saxena
    Expert 1985 points

    Hi Karan,

    Yes I tried to do it on stock SDK and it is work!!...Just look at the log:

    root@am57xx-evm:~# ip link
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
        link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000
        link/ether 90:9a:77:57:03:6c brd ff:ff:ff:ff:ff:ff
    3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000
        link/ether 90:9a:77:57:03:6d brd ff:ff:ff:ff:ff:ff
    4: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group default qlen 1000
        link/sit 0.0.0.0 brd 0.0.0.0
    5: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN mode DEFAULT group default qlen 10
        link/can
    6: eth2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group default qlen 1000
        link/ether 70:ff:76:1c:2d:8d brd ff:ff:ff:ff:ff:ff
    7: eth3: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group default qlen 1000
        link/ether 70:ff:76:1c:2d:8e brd ff:ff:ff:ff:ff:ff
    root@am57xx-evm:~# ip link set can0 type can bitrate 50000
    root@am57xx-evm:~# ip link set can0 up
    [ 2099.217735] c_can_platform 4ae3c000.can can0: setting BTR=1c18 BRPE=0000
    [ 2099.225346] IPv6: ADDRCONF(NETDEV_UP): can0: link is not ready
    [ 2099.233933] IPv6: ADDRCONF(NETDEV_CHANGE): can0: link becomes ready
    root@am57xx-evm:~# cansend can0 123#DEADBEEF
    [ 2117.914639] can: controller area network core (rev 20170425 abi 9)
    [ 2117.920935] NET: Registered protocol family 29
    [ 2117.930510] can: raw protocol (rev 20170425)

    When I do connection with oscilloscope I see the signal  which I sent.....

    I think it is work good on stock SDK. Did you check my files?

    BR,

    Oleg

  • 0 in reply to Oleg Solovev
    TI__Guru* 77774 points

    Hi Oleg,

    So as DCAN1 works, let us try to add the DCAN2 in the same way. So basically do not do any muxing in uboot and try to reference the attached patch to add DCAN2 in the kernel.

    /cfs-file/__key/communityserver-discussions-components-files/791/0001_2D00_Add_2D00_pinmux_2D00_for_2D00_DCAN2.patch

    Also, please note this is from another SDK so might not apply cleanly, if it doesn't apply cleanly then please take reference and add the nodes.

    Can you also tell me your SDK version, just wanted to make sure.

    Regards,

    Karan

  • 0 in reply to Karan Saxena
    Expert 1985 points

    Hi Karan,

    I applied your patch and everything is ok. I mean I didn't see some errors. But I have a question maybe it should be in section &dra7_pmx_core???

    so we also see added code here:

    Ok let's see what we have in linux...

    Like you understood I rebuild .dtb and add new .dtb on my boot device(SD_card).

    Like you see we still didn't have can1 in system...

    BR,

    Oleg

  • 0 in reply to Oleg Solovev
    TI__Guru* 77774 points

    Hi Oleg,

    Oleg Solovev said:
    But I have a question maybe it should be in section &dra7_pmx_core???

    Yes, the pinmux should be there inside the &dra7_pmx_core node. This will be needed for actual register address mapping from the offsets we provide. You can take reference from the patch I sent.

    You should see both the can interfaces. Can you check the dmesg and see if there was some error in the driver probe? run "dmesh | grep can" after the linux has booted. The interface does not depend on the Pinmux, if the node's status = okay in the device tree, I believe it should come up.

    Regards,

    Karan

  • 0 in reply to Karan Saxena
    Expert 1985 points

    Hello Karan,

    Could you explain me for what we need settings for pins in pinmix?

    I thought that the settings in the device tree work in tandem with the settings in the pinmux. But now you saed "The interface does not depend on the Pinmux".

    I downloaded a new SDK and rebuilt it. It looks like the DСAN is working....If I find a reason, I will definitely write about it.

    BR,

    Oleg

  • 0 in reply to Oleg Solovev
    TI__Guru* 77774 points

    Hi Oleg,

    Oleg Solovev said:
    Could you explain me for what we need settings for pins in pinmix?

    A PAD/Pin/Ball of the SoC has a number of signals which can come out of it. To select a particular signal out of those, you need to pinmux that particular PAD for that particular signal. 

    Oleg Solovev said:
    I thought that the settings in the device tree work in tandem with the settings in the pinmux. But now you saed "The interface does not depend on the Pinmux".

    The Pinmux is just doing one register write. This can happen in multiple places - u-boot (using mux_data.h) or in the Kernel's device tree.

    On AM57xx, we generally do the Pinmux in u-boot but I believe that due to the errata for DCAN (as mentioned in my previous email) - pInmux is happening in the Kernel.

    Regards,

    Karan

  • 0 in reply to Karan Saxena
    Expert 1985 points

    Hi Karan,

    Everything would be easy to understand, but u-boot has own device tree. Like you said: u-boot (using mux_data.h) or in the Kernel's device tree.

    Personally, it confuses me a lot when trying to configure this

    U-boot have am574x-idk.dts in own directory. For what?

    What do you say to that?

    BR,

    Oleg

  • 0 in reply to Oleg Solovev
    TI__Guru* 77774 points

    Hi Oleg,

    All the different components: u-boot and Kernel have their own device tree.

    u-boot will have a minimal device tree for the peripherals it needs to access, Kernel device tree will have some things additional to the u-boot. It can override the u-boot's config.

    Regards,

    Karan

  • 0 in reply to Karan Saxena
    Expert 1985 points

    Hi Karan,

    Thx so much for explanation and help

    BR,

    Oleg