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/PROCESSOR-SDK-AM335X: Conversion pinmux tool output to mux.c for u-boot

Part Number: PROCESSOR-SDK-AM335X

Tool/software: Linux

Hello all,

We use pinmux tool with the version 4.0.1522 and we are trying to add "am335x_pinmux.h" and "am335x_pinmux_data.c" files into u-boot source. Our psdk version is 05_01_00_11. It seems there is a conflict between generated output files,from pinmux, and mux.c files. I mean, for example, the below code is from "am335x_pinmux_data.c" file

static pinmuxPerCfg_t gUart0PinCfg[] =
{
    {
       /* Debug -> uart0_rxd -> E15 */
       PIN_UART0_RXD, 0, \
       ( \
           PIN_MODE(0) | \
           ((PIN_PULL_UD_EN | PIN_RX_ACTIVE) & (~PIN_PULL_TYPE_SEL)) \
       ) \
    },
    {
       /* Debug -> uart0_txd -> E16 */
       PIN_UART0_TXD, 0, \
       ( \
           PIN_MODE(0) | \
           ((PIN_PULL_UD_EN) & (~PIN_PULL_TYPE_SEL & ~PIN_RX_ACTIVE)) \
       ) \
    },
    {PINMUX_INVALID_PIN}
};

and the below code snippet is taken from mux.c 

static struct module_pin_mux uart0_pin_mux[] = {
	{OFFSET(uart0_rxd), (MODE(0) | PULLUP_EN | RXACTIVE)},	/* UART0_RXD */
	{OFFSET(uart0_txd), (MODE(0) | PULLUDEN)},		/* UART0_TXD */
	{-1},
};

Do we need to do any conversion? or are there any way to use generated files directly?

  • Hello Oguzhan,

    Due to the US holidays, on this particular E2E thread, our response may get delayed until the week of Jan 2, 2019.

    Warmest Wishes for Happy Holidays and a Happy New Year!

    best regards,
    David Zhou
  • The am335x_pinmux_data.c file you mentioned is intended for use with RTOS/starterware.  For Linux you should use the devicetree.dtsi file.  U-boot should configure only the minimal pins required to load Linux.  Often that pin muxing has already been done by the boot ROM in order to load u-boot itself.  Any u-boot pinmux changes will need to be made manually.

  • Thank You Brad! One more question I want to ask. Does u-boot need am335x-evm.dtb? I could not be sure where the pin settings should be done for u-boot. We could not complete peripheral initialization on uboot.  Below is the uboot log. Probably none of the environment could succesfully init. After a while, we can see the uboot console (=>) But as I said, none of the peripheral is initialised successfully.

    Now running in RAM - U-Boot at: 8ff3c000
    NAND:  0 MiB
    MMC:   OMAP SD/MMC: 0
    ** Bad device mmc 0 **
    Using default environment
    <ethaddr> not set. Validating first E-fuse MAC
    Net:   PHY reset timed out
    cpsw, usb_ether
    Hit any key to stop autoboot:  2  1  0 
    MMC Device 1 not found
    no mmc device at slot 1
    MMC Device 1 not found
    no mmc device at slot 1
    ## Error: "bootcmd_nand0" not defined
    starting USB...
    USB0:   Port not available.
    cpsw Waiting for PHY auto negotiation to complete......... TIMEOUT !
    using musb-hdrc, OUT ep1out IN ep1in STATUS ep2in
    MAC 0c:1c:57:69:87:9f
    HOST MAC de:ad:be:ef:00:00
    RNDIS ready
    missing environment variable: pxeuuid
    Retrieving file: pxelinux.cfg/01-0c-1c-57-69-87-9f
    cpsw Waiting for PHY auto negotiation to complete......... TIMEOUT !

  • Let me clarify on my previous answer.  When I mentioned using the devicetree.dtsi file, I was suggesting specifically to use that in Linux.  Because u-boot also uses device tree it can sometimes be confusing.  So to clarify:

    1. In the u-boot board directory, there's a mux.c file.  You will need to manually edit that file to implement any pin muxing requirements for u-boot.
    2. The auto-generated devicetree.dtsi file should be incorporated into your Linux device tree to handle the rest of the pins.

    The u-boot device tree is utilized to some degree, but much less than Linux.  Not all drivers have device tree support, and the drivers in general support fewer features than what you get in Linux.

    I recommend starting a new thread if you are trying to debug a specific boot issue, i.e. the thread is starting to move away from pinmux questions.