Please note that E2E has undergone a major upgrade. Before logging in, please clear ALL your browser's cache and cookies.

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.

AM6528: mcu-uart as the console for uboot and the kernel

Part Number: AM6528

Hi

I like to use the MCU-uart as the console for uboot and the kernel? I understand that if i do then the safety MCU section has to be powered up. But because we don't have enough UARTs on the device we dont have a choice. Also can the DMSC UART be used by the A53?

The 2nd question would be how to configure the dts files to get the MCU-uart as the console if that is possible.

Thanks

  • Hi Mohsen,

    A53 can access MCU_UART, so yes, MCU_UART can be configured as the console for U-Boot and Linux.

    I can use uart test tool to read/write MCU_UART in Linux, so the port is up in Linux. You just have to modify the DTS file and U-Boot bootargs to let MCU_UART be the Linux console. If you are asking for a custom board, please ensure the PINMUX setting for MCU_UART pins are correct. The procedure is applicable to all Sitara platforms. So if you need to know the details how to modify DTS and U-Boot bootargs, please search on this forums. The similar question has been asked and answered multiple time here.

    Similar for configuring MCU_UART as U-Boot console, you can search it on this forums too. But I would have to check if MCU_UART is powered up in U-Boot or not once I am back in office next week. If not, this would be an extra step.

  • Bin Liu said:
    Similar for configuring MCU_UART as U-Boot console, you can search it on this forums too. But I would have to check if MCU_UART is powered up in U-Boot or not once I am back in office next week. If not, this would be an extra step.

    As for U-Boot, I've done this before, and while (just like Bin) I currently don't have access to AM654x hardware to re-validate the steps, below is a list from my records of what needs to be changed. The complication is that during System Firmware "PM Init" the clock frequency used for the MCU_UART0 changes from 48MHz to 96MHz, and this will need to be comprehended in the code (the below steps do that). Because if not you will loose your console during SYSFW startup.

    First, change to using stdout-path = "serial1:115200n8" in both k3-am654-r5-base-board.dts and k3-am654-base-board.dts

    Then, disable CONFIG_K3_EARLY_CONS in the configs/am65x_evm_r5_defconfig file

    Then, add this towards the top of arch/arm/mach-k3/am6_init.c

    #include <ns16550.h>
    
    DECLARE_GLOBAL_DATA_PTR;

    Then, move the call below towards the top of board_init_f(), specifically, move it to right after(!) spl_early_init().

    	/* Prepare console output */
    	preloader_console_init();

    Add the below to the very top of k3_init_post_pm_cb(). This will comprehend the UART clock frequency change.

    	/*
    	 * Now with the SYSFW having the PM configuration applied successfully,
    	 * our MCU_UART0 functional clock just changed from 48MHz to 96MHz.
    	 * Reconfigure the console UART driver accordingly so we can continue
    	 * using it like nothing ever happened.
    	 */
    	if (gd->cur_serial_dev) {
    		struct NS16550 *const com = dev_get_priv(gd->cur_serial_dev);
    		struct ns16550_platdata *plat = com->plat;
    
    		plat->clock = 96000000;	/* As set through SYSFW PM config */
    
    		serial_setbrg();
    	}

    This should do the job for U-Boot.

    Now, for Kernel, you'll need to update arch/arm64/boot/dts/ti/k3-am654-base-board.dts to point to stdout-path = "serial1:115200n8";

    Then, you also have to add the below to that same file:

    &mcu_uart0 {
    	status = "okay";
    };

    For cleanness-sake this node should probably include a pinmux reference as well (similar to how main_uart0 is setup) although it should work without it as U-Boot is already setting up pinmux. If you want to add it you could borrow the respective definitons from the U-Boot device tree file.

    Plus, what Bin mentioned, the Kernel's bootargs= would also need to get updated to the new UART so that it doesn't conflict with what was setup through stdout-path, and bootargs actually resides in U-Boot. Be careful after changing this in U-Boot to reset the U-Boot environment to ensure any new ENV settings that come in via code changes are actually present and available.

    Regards, Andreas