DRA75: Not able to see an output for EMAC example project when integrated with IPC for early boot

Hi Padmesh,

The PDK examples are designed to run in a standalone environment and assume full SoC resource ownership in order to demonstrate all aspects needed to successfully use the module of interest.  They are intended to be loaded through CCS Debug session or through the RTOS SBL.  When loading through u-boot/Linux, there are many more considerations and modifications required, so there are various reasons why you may not be seeing the expected result.  Let me give a modification checklist:

1. Most peripherals cannot be used in both RTOS and Linux without some significant engineering effort, so we must carefully remove those from each context.  For instance in your case:
   1. Remove UART from the PDK example.
   2. Remove CPSW/EMAC and MDIO from Linux device tree and kernel so that nothing attempts to access these resources or respond to any signals/interrupts from them.
   3. I2C1 is needed to take PHYs out of reset and configure board mux to select EMAC0 pins.  It's also needed by Linux for PMIC and in general for many other modules on the board.  This initialization code needs to be ported from PDK board library into u-boot, and then you must remove I2C from the PDK

2. PDK does all necessary platform initialization.  In particular, IODelay reconfiguration is a critical step and must be done when the SoC pads are in isolation.  This is typically done one time in u-boot or SBL, but PDK examples also do it when running in a standalone debug session from CCS.  This must be removed from the PDK Board library as well.  See http://software-dl.ti.com/processor-sdk-rtos/esd/docs/04_03_00_05/rtos/Board_EVM_Abstration.html#considerations-for-dra7xx-devices for more details on this and how to achieve
3. Memory map must be consistent between Linux and the PDK application.  In Linux the device tree will define the cma pools for each DSP/IPU.  The memory placement in the PDK example will need to match this.  If not, you must modify one or the other.

Lastly, I recall helping Ganesh from your company recently on similar things.  He will already have done some of these and may be a good resource for you to consult locally for more specifics on the code changes.

Thanks,
Stephen

Hi Padmesh,

I have more feedback on this now.  The recommendation is that the below flags are added to modules to be exercised from M4 (or any other remote-core), and which need from A15(Linux)

&<peripheral-id>{
ti, no-idle;
ti, no-reset-on-init;
status=”disabled”;
};

You will need to do this for the 'mac' peripheral in your dts file.

Other code required for board initialization and releasing the PHY from reset should be already taken care of in u-boot as it is currently used for NFS mounts in other scenarios.

Thanks,
Stephen

Hi Padmesh,

You should be disabling the peripherals needed in the Linux kernel device tree. For u-boot, you can disable whatever there that you plan to handle from the RTOS app. In many cases this may not be practical; for instance the shared I2C bus needed for releasing PHY from reset and setting the right board mux as well as handling many other device initializations. Other accesses which don't require some shared resource, e.g. CPSW controller, can be done entirely in the RTOS app.

Knowing which peripherals are needed must be decided by studying the app you are using. In the EMAC basic example, you should be removing from the RTOS app all PRCM, I2C, UART, pad and IODelay config access. The app should keep MDIO, CPSW, interrupt config/routing for M4. Anything else custom you may be adding will need to be evaluated as well.

Thanks,
Stephen