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.

TDA4VM: Issues conecting via Ethernet to EVM when using SBL but not when using SPL

Part Number: TDA4VM
Other Parts Discussed in Thread: TDA4VL,

Hello Ti.

To speed up development process, we modify applications in rootFS via ethernet and SCP from host.

To do that, once SPL loads system and ARAGO is running, we configure eth interface (with proper IP and Mask). To confrim averything is ok, a ping is launched to the host.

After that, SCP trasnsfer is fine.

But when we launch TDA4 via SBL, with multiimage in OPTIMIZED mode, conection fails using same configurations.

Ping is not reached and after a while (arounfd 15s) CoreDump happens:

Then, we can not transfer SCP (neither other protocol via ethernet) files when run via SBL but yes when we run via SPL.

We need to work in SBL mode.

Could you give support on this?

(here he complete log when startup is done via SBL)

Log_When_SBL_EthInterface.zip

Thanks

  • Hi,

    May I know what "./configure_network.sh " is doing?
    From the log it seems link is up very early, but this script is executing very late from the below logs.


    [   31.355132] am65-cpsw-nuss 46000000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
    PING 192.168.50.1 (192.168.50.1): 56 data bytes
    [ 85.064596] ------------[ cut here ]------------
    [ 85.069213] NETDEV WATCHDOG: eth0 (am65-cpsw-nuss): transmit queue 0 timed out


    Is there any application sending the data to CPSW2G before running the script?

    Best Regards,
    Sudheer

  • Hi,

    The script is nothing special, is what is shown in snapshot.

    The script configures eth0 IP and Mask and sends ping to host conected via Ethernet. This works perfectly when SPL is used.

  • Hi,

    Can you please confirm, are you using Native Linux driver or Virtual MAC driver with EthFW?

    But when we launch TDA4 via SBL, with multiimage in OPTIMIZED mode, conection fails using same configurations.

    If you run in normal mode instead of applying the optimization, is it working fine?

    Can you please specify the images being loaded using SBL?

    Best Regards,
    Sudheer

  • Hello Doredla,

    We have not changed any driver. Drivers and Kernel is what is provided by SDK. Minor changes where done in DTS to remove conflicts in UARTs and CAN/CANtrasnceiver as we are also running one non Vision application in MCU1_0.

    If you run in normal mode instead of applying the optimization, is it working fine?

    We can not run in that mode as there are some issues that are under resolution by TI (there are other posts for that...: PROCESSOR-SDK-J721E: SBL for HLOS sd card fails in SCI client ).

    Can you please specify the images being loaded using SBL?

    The images loaded are:

    bl21, bl32, kernel image (all three equal than provided by SDK) , DTB, mcu2_0 firmware (vision app), mcu2_1 firmware (vision app), C66_1 fw (vision_app), C62_1 fw (vision_app), C7x_1.

    BR

  • Hi,

    Can you please confirm, is the applications running in case of SBL and SPL were same?
    If not can you share the details about what is difference?

    Best Regards,
    Sudheer

  • Yes, I use the same.

    BR

  • Hi Doredla,

    Do you have any update on this?

    Many thanks

  • Hi,

    Sorry for the delayed response.

    We are able to reproduce the issue (We tried on TDA4VL), It is because of CTRLMMR registers are locked by default.
    Same issue might be TDAVM as well.

    In case of development boot (SBL) or SPL u-boot is unlocking all CTRLMMR blocks so that Interface selection is reflecting in ENET_CTRL register.

    In case of optimized boot flow (SBL), where u-boot is not present and SBL loads Linux image no one is unlocking the CTRL MMR blocks so, interface selection to RGMII from ENET_CTRL is not happening as register is locked. (write will not affect the value in register).
    This is the reason where you see interface is still RMII even in device tree interface configured as RGMII.

    Fix for above:
    Unlock the the CTRLMMR registers in SBL or Linux.

    Please refer to below changes and add the patch to <PSDK-RTOS>/pdk/packages/ti/boot/sbl/k3/sbl_main.c, where we are unlocking all CTRLMMR from sbl.

     
    +#define WKUP_CTRL_MMR0_BASE			0x43000000
    +#define MCU_CTRL_MMR0_BASE			0x40f00000
    +#define CTRL_MMR0_BASE				0x00100000
    
    
    +/*
    + * The CTRL_MMR0 memory space is divided into several equally-spaced
    + * partitions, so defining the partition size allows us to determine
    + * register addresses common to those partitions.
    +*/
    +#define CTRL_MMR0_PARTITION_SIZE		0x4000
    
    +/*
    + * CTRL_MMR0, WKUP_CTRL_MMR0, and MCU_CTRL_MMR0 lock/kick-mechanism
    + * shared register definitions. The same registers are also used for
    + * PADCFG_MMR lock/kick-mechanism.
    +*/
    +#define CTRLMMR_LOCK_KICK0			0x1008
    +#define CTRLMMR_LOCK_KICK0_UNLOCK_VAL		0x68ef3490
    +#define CTRLMMR_LOCK_KICK1			0x100c
    +#define CTRLMMR_LOCK_KICK1_UNLOCK_VAL		0xd172bc5a
    
    
    +void CTRL_MMR_unlock(volatile uint32_t baseAddr, uint32_t partition)
    +{
    +	/* Get the part base address */
    +	uint32_t partBaseAddr = baseAddr + (partition * CTRL_MMR0_PARTITION_SIZE);
    +
    +	/* Unlock the requested partition if locked using two-step sequence */
    +	*(volatile uint32_t *)(partBaseAddr + CTRLMMR_LOCK_KICK0) = CTRLMMR_LOCK_KICK0_UNLOCK_VAL;
    +	*(volatile uint32_t *)(partBaseAddr + CTRLMMR_LOCK_KICK1) = CTRLMMR_LOCK_KICK1_UNLOCK_VAL;
    +}
    +
    +static void SBL_CTRL_MMR_unlock_all(void)
    +{
    +	/* Unlock all WKUP_CTRL_MMR0 module registers */
    +	CTRL_MMR_unlock(WKUP_CTRL_MMR0_BASE, 0);
    +	CTRL_MMR_unlock(WKUP_CTRL_MMR0_BASE, 1);
    +	CTRL_MMR_unlock(WKUP_CTRL_MMR0_BASE, 2);
    +	CTRL_MMR_unlock(WKUP_CTRL_MMR0_BASE, 3);
    +	CTRL_MMR_unlock(WKUP_CTRL_MMR0_BASE, 4);
    +	CTRL_MMR_unlock(WKUP_CTRL_MMR0_BASE, 6);
    +	CTRL_MMR_unlock(WKUP_CTRL_MMR0_BASE, 7);
    +
    +	/* Unlock all MCU_CTRL_MMR0 module registers */
    +	CTRL_MMR_unlock(MCU_CTRL_MMR0_BASE, 0);
    +	CTRL_MMR_unlock(MCU_CTRL_MMR0_BASE, 1);
    +	CTRL_MMR_unlock(MCU_CTRL_MMR0_BASE, 2);
    +	CTRL_MMR_unlock(MCU_CTRL_MMR0_BASE, 3);
    +	CTRL_MMR_unlock(MCU_CTRL_MMR0_BASE, 4);
    +
    +	/* Unlock all CTRL_MMR0 module registers */
    +	CTRL_MMR_unlock(CTRL_MMR0_BASE, 0);
    +	CTRL_MMR_unlock(CTRL_MMR0_BASE, 1);
    +	CTRL_MMR_unlock(CTRL_MMR0_BASE, 2);
    +	CTRL_MMR_unlock(CTRL_MMR0_BASE, 3);
    +	CTRL_MMR_unlock(CTRL_MMR0_BASE, 5);
    +	 #if defined(SOC_J721S2)
    +		CTRL_MMR_unlock(CTRL_MMR0_BASE, 6);
    +	#endif
    +	CTRL_MMR_unlock(CTRL_MMR0_BASE, 7);
    +}
    
    
    int main()
    {
       ......
       
        /* Any SoC specific Init. */
        SBL_SocEarlyInit();
    
    +    /* Unlock control MMR registers */
    +    SBL_CTRL_MMR_unlock_all();
    
        if (SBL_LOG_LEVEL > SBL_LOG_ERR)
        {
            /* Configure UART Tx pinmux. */
            Board_uartTxPinmuxConfig();
        }
    
    


    After taking above changes build "sbl_mmcsd_img_hlos" and "sbl_lib_mmcsd_hlos" as follows.
    Follow step-5 and step-7 from FAQ [SBL flow with combined app image].

    Note:
    In above FAQ, TDA4VL is the reference SOC so you can follow the same steps with J721E (TDA4VM)

    Best Regards,
    Sudheer

  • Hi Doredla,

    Is this patch planning to be integrated in forthcoming SDK releases?

    Many thanks

    Mònica

  • Hi Monica,

    I have created an Internal JIRA for the same, will try to integrate in upcoming SDK releases.
    As SBL is a customizable it is okay to add whatever is required by customer.

    Best Regards,
    Sudheer

  • Hi Sudheer,

    Thanks, could you please update the ticket with the version once you know it so we can keep track?

    Many thanks

    Mònica

  • Hi Monica,

    Thanks, could you please update the ticket with the version once you know it so we can keep track?

    Sure, will update the ticket with the SDK version, once I got update from internal SDK Team.

    Best Regards,
    Sudheer

  • Hi,

    Our SBL team recommended to provide the patch to customers from application point of view also, it is customizable so, customer can modify it.
    We have created an FAQ for this issue, please refer if required in future.

    Will be closing this thread.

    Best Regards,
    Sudheer