Banner_AURIX_Security-Solution Banner_AURIX_Safety_Products ShieldBuddy TC275 Banner_AURIX_OnzerOS


infineon4engi@twitter twitter

infineon4engineers Facebook

infineon@linkedin linkedin

infineon@youtube youtube


+ Reply to Thread
Results 1 to 6 of 6
  1. #1
    Beginner Beginner TMorita is on a distinguished road
    Join Date
    Dec 2018
    Posts
    5
    Points
    105

    iLLD Ethernet driver bug list

    Here's a list of bugs I have found in the iLLD Ethernet driver:

    1. If the interface is configured as RMII, the code fails to configure the SMI (MDC/MDIO) pins.

    2. The pin mux tables contain incorrect mux data for Ethernet for some pins.
    So if the SMI interface is not working, the pin mux table for the pins you are using must be manually verified.

    3. IfxEth_wakeupTransmitter() and IfxEth_wakeupReceiver() are broken.
    They do not start the transmitter/receiver if the transmitter/receiver are in the STOPPED state after reset.

    4. The Tricores have a data cache.
    The Ethernet GMAC uses DMA to access descriptors and buffers.
    The Ethernet GMAC DMA is not cache-coherent.
    The Ethernet drivers do not account for this.

    Helpful tip:

    1. You MUST clear ALL bits in the ETH_STATUS register before exiting from the Ethernet interrupt handler.
    If ANY bits are left set, it will prevent the interrupt from being triggered again.

    This should provide a starting point for fixing the Ethernet code if you are using it.
    I do not work for Infineon, so do not post or send me questions about this.
    I will not provide tech support for any problems mentioned in this post.

    Toshi

  2. #2
    Advanced Advanced UC_wrangler is on a distinguished road
    Join Date
    Jun 2019
    Posts
    51
    Points
    1070
    Hi Toshi. It's important to note that DMA is never cache-coherent on the AURIX. That holds true for Ethernet DMA and the regular DMA controller.

    I usually suggest that CPUx_PMA0 should be set to 0x100 (cache PFLASH segment 8), rather than the default 0x300 (segment 8 and LMU segment 9). That way, access to constants in PFLASH is still boosted with the data cache, but there are no cache coherency issues between CPU cores or with DMA.

  3. #3
    Advanced Advanced
    Infineon Employee
    Infineon Employee
    MoD is on a distinguished road
    Join Date
    Feb 2012
    Location
    Munich
    Posts
    71
    Points
    1344.375
    You can use also segment 0xB for accesses from CPU to LMU. This segment is uncached, this means each access to segment 0xB will go to the destination independent of the cache settings.
    The views expressed here are my personal opinions, have not been reviewed or authorized by Infineon and do not necessarily represent the views of Infineon.

  4. #4
    Beginner Beginner TMorita is on a distinguished road
    Join Date
    Dec 2018
    Posts
    5
    Points
    105
    UC wrangler wrote:

    > Hi Toshi. It's important to note that DMA is never cache-coherent on the AURIX.
    > That holds true for Ethernet DMA and the regular DMA controller.


    The DMA not being cache-coherent is not an AURIX architecture issue per se.
    This is due to a design choice made on current AURIX implementations not to support bus snooping on DMA access.
    So stating "DMA is never cache-coherent on the AURIX" is an overly broad blanket statement.
    There is nothing in the AURIX architecture which precludes future implementations from supporting cache coherency.

    > I usually suggest that CPUx_PMA0 should be set to 0x100

    If I understand correctly, this disables caching of RAM.
    Since LMU/EMEM accesses go over the crossbar, this probably increases load/store latency by two or three clocks due to external bus access and crossbar arbitration.
    Based on my previous experience performing dynamic instruction set analysis at a previous job, the typical dynamic instruction mix for non-numeric applications is about 20% branches, 25% load/stores, and 55% ALU instructions.
    Assuming a 25% load/store instruction mix and a three-clock load/store penalty, this will result in a performance penalty of 75% + (25% * 3) = 150%.
    Stated otherwise, the code will probably run about 1.5x slower if caching is disabled for RAM as you recommend.
    So in my opinion, this is a sloppy way of solving the cache coherency issue because the performance penalty is very high.
    It is much better to selectively place the data structures which are shared between the CPU and DMA in an uncached address range to avoid incurring this performance penalty.

    Toshi
    Last edited by TMorita; Nov 26th, 2019 at 03:16 PM.

  5. #5
    Advanced Advanced UC_wrangler is on a distinguished road
    Join Date
    Jun 2019
    Posts
    51
    Points
    1070
    > There is nothing in the AURIX architecture which precludes future implementations from supporting cache coherency.

    I am constraining my discussion to AURIX variants that actually exist

    > So in my opinion, this is a sloppy way of solving the cache coherency issue because the performance penalty is very high.
    It is much better to selectively place the data structures which are shared between the CPU and DMA in an uncached address range to avoid incurring this performance penalty.


    I agree with your statement in principle - but over time, as variables are added to applications by developers who are not aware of the AURIX architecture, eventually someone puts something in the wrong place. In my experience, tracking down cache coherency problems is not worth the trouble. Your mileage may vary.
    Last edited by UC_wrangler; Nov 27th, 2019 at 08:56 AM.

  6. #6
    Beginner Beginner TMorita is on a distinguished road
    Join Date
    Dec 2018
    Posts
    5
    Points
    105
    Few more bugs I have found in iLLD code:

    5. The iLLD Ethernet driver configures the Ethernet MAC to drop packets < 64 bytes long.
    Ethernet ARP replies are usually 42 bytes long, so this causes ARP to fail.

    6. The iLLD Ethernet demo does not configure a valid MAC address.

Disclaimer

All content and materials on this site are provided “as is“. Infineon makes no warranties or representations with regard to this content and these materials of any kind, whether express or implied, including without limitation, warranties or representations of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, whether express or implied, is granted by Infineon. Use of the information on this site may require a license from a third party, or a license from Infineon.


Infineon accepts no liability for the content and materials on this site being accurate, complete or up- to-date or for the contents of external links. Infineon distances itself expressly from the contents of the linked pages, over the structure of which Infineon has no control.


Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Usage Terms of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Usage Terms of this site. Infineon reserves the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.